选题是唯一一个"选择大于努力"的环节
功能可以砍，文档可以改，但题目一旦定下来，调整成本极高。判断一个题目是否合适，我通常用三个标准。
标准一：能否说清一个"具体问题"
好题目描述的是一个具体场景下的具体问题，而不是一个技术名词。
- 反例：基于 SpringBoot 的电商系统
- 正例：面向校园二手书流转的信用交易平台
区别在于：后者能直接回答"解决谁的什么问题"，前者只能回答"用了什么技术"。
标准二：核心功能能否收敛到 3–5 个
功能数量是可控性的直接体现。
核心功能（必须做，决定项目是否成立）
├── 用户与权限
├── 商品/内容发布
├── 核心业务流程（下单/申请/预约）
└── 数据统计或状态跟踪
加分功能（有余力再做）
├── 消息通知
├── 数据可视化
└── 推荐/智能匹配
如果核心功能超过 5 个，通常意味着题目过大；如果一个都不需要写，那是课程作业不是毕业设计。
标准三：有没有一个能讲深的技术点
答辩的分数差异，往往来自"有没有讲深的地方"。
不必是前沿技术，只要你能讲清取舍就成立：
- 为什么用缓存，缓存了什么，怎么保证一致性
- 状态流转为什么这样设计，如何防止非法状态
- 权限模型为什么这么抽象，扩展新角色要改哪里
一个能展开讲三分钟的技术点，比十个只会说"用了"的技术栈有价值得多。
一个快速自检清单
- 能用一句话说清解决谁的什么问题
- 核心功能不超过 5 个
- 至少有一个可以深入讨论的技术点
- 能在规定周期内完成，且留有缓冲
- 有可获取的真实或模拟数据支撑
五项都能打勾，这个题目大概率是稳的。
小结
选题不是找最炫的技术，而是找你能讲清楚的最小完整问题。把范围收敛好，后面每一步都会轻松很多。
