核心产品亮点与用户体验设计
毕业设计选题涉及教师、选题负责人、学生和管理员。课题从提出到最终落位，需要经过发布、审核、开放、预选、确认与统计多个阶段。系统把这些环节放进同一个工作流，让不同角色看到各自该处理的事项，也让题目状态和名额变化有清晰的归属。
1. 从教师出题到负责人审核：让课题进入可选范围
- 教师按规则维护课题：教师填写标题、类型、描述、学生要求、容量及适用选题组，随后在列表中查看发布与审核状态。被打回的题目可根据意见修改并重新提交审核。
- 负责人处理审核回路：负责人查看所属范围内的待审核课题，选择通过或填写打回理由。审核结果回到教师侧，减少课题发布过程中反复线下确认的成本。
2. 从浏览到最终确认：把学生选题拆成清楚的阶段
- 先看详情，再作预选：学生按教师或学院查找题目，核对题目要求、指导教师、剩余名额和开放时间。开放预选后，每名学生最多可预选 10 个题目，为最终选择保留比较空间。
- 一个最终题目与可追踪结果：进入学生选题阶段后，学生从可选题目中确认并提交一个最终题目，再在“查看选题”页面核对结果。需要调整时，按照当前阶段的规则取消预选或申请退选。
3. 院系统筹与进度可视化：让管理动作有依据
- 基础资料与开放规则集中配置：管理员维护学院、专业、选题组及各角色账号，并在管理端配置题目开放时间和相关选题规则；账号与组织关系决定不同角色的可见范围。
- 统计与导出辅助跟进：选题负责人查看已选、未选学生的进度分布，按需导出名单，便于对尚未完成选题的学生继续跟进。
4. 前后端分离的业务承载
- 角色化页面与统一接口：前端使用 React、TypeScript、Umi Max 和 Ant Design Pro 组织工作台；后端由 Spring Boot、Spring MVC、MyBatis-Plus 和 Sa-Token 承担接口、数据访问与角色校验。
- 状态与名额约束落在服务端：选题相关操作由后端事务、数据库约束与必要的锁协同保护；MySQL 保存业务数据，Redis 承担会话与缓存能力，避免只凭页面状态判断选题结果。
展示图片包含本地运行实录与项目仓库中的功能演示截图；演示账号和选题数据用于说明流程，不代表真实教务数据。