Java毕业设计：基于Spring Boot的升学志愿填报系统设计与实现-开发者社区

每年毕业设计，Java选题几乎占掉半壁江山，但真正能把一套系统从设计、编码、部署到讲清楚每个业务为什么这么做的，确实不多。今天要聊的这个项目，是一套基于Java的毕业生升学志愿填报系统，也可以叫高校毕业生志愿申报与录取管理平台，核心就是让毕业生、企业/院校、辅导员和管理员四类角色，在同一个页面里完成从升学就业信息发布、志愿申报、学校审核到录取公示的完整闭环。

很多同学拿到这种题目，第一反应是“不就是个CRUD吗”。说实话，如果只是把增删改查写完，确实不难；但这个课题真正值钱的地方，在于志愿填报业务的状态流转、多角色权限控制、并发场景下的数据一致性，以及录取统计的准确性。你在面试时能不能把这些点讲出深度，往往就决定了面试官是把你当“会写代码的工具人”，还是当成“能独立解决问题的开发”。下面我会把这套系统的设计思路、数据库表结构、核心代码实现、避坑经验全部复盘一遍，希望能帮正在做Java毕设或者准备实习项目的朋友，省下一两个月的摸索时间。

1. 项目概述：一套志愿填报系统的真实业务链路

1.1 这个系统要解决的到底是什么问题

每年毕业季，高校就业指导中心和企业招聘之间的信息流转，往往还停留在“Excel汇总 + 群通知 + 手动统计”的阶段。学生面对大量就业岗位和升学计划，不知道哪些适合自己；学校想统计学生志愿申报情况，却要从几十个辅导员手里收表格，再人工合并去重。信息不一致、时间节点错过、数据统计口径混乱，这些问题几乎是每年都会发生。

这套系统的核心目标，就是把“企业/院校发布升学就业信息 → 毕业生查看和筛选 → 填报志愿 → 学校审核 → 录取结果公示 → 数据统计导出”这条链路搬到线上，让每个环节的数据都有迹可循。它不只是一个简单的信息发布网站，而是一个带审批流、带状态机、带多角色权限的中小型业务系统，这也是它能成为毕业设计优秀选题的重要原因。

1.2 用户角色划分与核心需求

我在做需求分析的时候，把用户分成了四类，每一类的痛点都不一样：

毕业生：希望快速找到符合自己专业、意向城市、岗位类型的升学与就业信息，能够在线填报志愿，随时查看审核进度和录取结果。
企业/院校：希望发布招聘或升学计划后，能够批量查看申报学生列表，对学生的志愿进行筛选、通过或驳回，并能导出名单。
辅导员/审核教师：需要对本专业或本班级学生的志愿申报情况进行审核，同时能查看本学院的整体填报率。
系统管理员：负责用户管理、院系管理、基础数据维护、信息分类设置，以及最终的数据统计和系统参数配置。

角色定下来之后，整个系统的功能边界就非常清晰了。每个角色只能操作自己权限范围内的数据，比如学生不能修改别人的志愿，企业不能看到超出自己单位发布范围的数据，辅导员只能审核本专业的学生。

1.3 系统功能清单与业务流程概览

整个系统我拆成了六大模块：

用户认证模块：注册、登录、密码加密、令牌管理。
升学就业信息模块：企业/院校发布、修改、下架信息，管理员审核信息。
志愿申报模块：学生查看信息、填报志愿、修改/撤回志愿，辅导员审核。
审核与录取模块：企业对申报学生进行录取操作，系统生成录取名单，公示查询。
数据统计模块：按学院、专业、班级统计志愿填报率、录取率，支持导出Excel。
系统管理模块：用户管理、角色权限设置、院系专业管理、操作日志。

业务流程主线是这样的：企业发布信息 → 管理员审核通过 → 学生浏览并填报志愿（每个学生可填多个志愿，但同一批次同一专业只能填一次） → 辅导员审核志愿资格 → 企业查看申报列表并筛选录取 → 录取结果公示 → 学生确认。整个流程涉及多个状态的切换，我用状态机来管理，比直接在一堆if else里写死要清晰得多。

2. 技术选型与开发环境准备

2.1 后端技术栈：为什么是 Spring Boot + MyBatis Plus

项目是基于Java的，后端我选的是Spring Boot 2.7.x，没有去追最新的3.x。原因很简单：毕设项目求稳。Spring Boot 2.7 的社区资料最多，遇到问题随便一搜就有答案，而且对JDK 8和JDK 11都友好。很多同学一上来就装JDK 17 + Spring Boot 3，结果各种依赖不兼容，光配环境就耗了一周。

持久层用的是MyBatis Plus，而不是原生MyBatis。说实话，如果是纯手写SQL，原生MyBatis更灵活，但MyBatis Plus内置了分页插件、条件构造器、逻辑删除、自动填充这些功能，写业务代码的效率高很多。比如分页查询，只用写一句：

Page<JobInfo> page = new Page<>(current, size); LambdaQueryWrapper<JobInfo> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(JobInfo::getStatus, 1) .like(StringUtils.hasText(keyword), JobInfo::getTitle, keyword) .orderByDesc(JobInfo::getCreateTime); jobInfoMapper.selectPage(page, wrapper);

这一句就把条件判断、模糊查询、排序、分页全搞定了，比在XML里写一堆动态SQL要清爽太多。它生成的SQL也支持常见的索引利用，性能在毕设场景下完全够用。

2.2 JDK、Maven 环境配置和版本选择

每次给同学远程看环境问题，最常踩的坑就是JDK版本和编译版本不一致。比如你的项目pom.xml里配的是：

<properties> <java.version>1.8</java.version> </properties>

然后你本机装的是JDK 17，IDE里项目SDK也选了17，那编译的时候可能就会看到“java: 警告: 源发行版 17 需要目标发行版 17”或者“无效的目标发行版”这类报错。这个问题的本质是：编译器的source和target版本与当前JDK不匹配。

我建议把pom里显式加上这样一段：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.8</source> <target>1.8</target> <encoding>UTF-8</encoding> </configuration> </plugin>

同时，IDE里把Java Compiler的字节码版本也改成1.8，JRE用JDK 17其实没问题——高版本JDK可以向下编译到低版本字节码，只要source/target对应好。如果你是完全新手，建议老老实实装JDK 8，不要去折腾“最新版”，JDK 8在Java求职和毕设场景下依然是绝对主流。

环境变量配置也顺手说一下：JAVA_HOME指向JDK安装目录，Path里加上%JAVA_HOME%\bin，然后在命令行执行java -version验证。很多人在这一步出错，是因为装了多个版本的JDK，Path里前一个版本把后一个覆盖了。最佳实践是只保留一个JDK在Path里，其他版本留着备用，用IDE指定。

2.3 前端与数据库选型

前端我选的是Vue 2 + Element UI，没有上Vue 3和TypeScript。不是不会，而是项目要求的就是Java为主，前端只要能配合联调、界面整洁就够了。Vue 2 + Element UI的组件生态成熟，网上模板多，做后台管理类界面几乎是开箱即用。

数据库用MySQL 8.0，字符集统一utf8mb4，排序规则utf8mb4_general_ci。为什么强调utf8mb4？因为如果用户输入了特殊Emoji符号，或者名字里有生僻字，utf8mb3存储会报错。用utf8mb4是通用做法，反正也不影响查询性能。

Redis在这里不是必须的，但如果想给项目加分，可以把“热门职位列表”和“学生的待办提醒”做成缓存。我当时加了Redis做登录token的存储和简单的热点数据缓存，面试时聊到缓存策略，明显让对方觉得这个项目有考虑。

2.4 工程目录规划与代码分层

一个容易被忽视但极其重要的点，是代码结构。我见过很多毕设代码，所有Controller写在一个类里，Service层跟Mapper混在一起，改一个功能牵扯出一堆报错。

我用的分层结构是这样的：

com.university.volunteer ├── controller # 接口层，只做参数接收和结果包装 ├── service # 业务层，处理具体业务逻辑和事务边界 │ └── impl ├── mapper # 数据访问层，继承BaseMapper ├── entity # 数据库实体类 ├── dto # 接口传输对象，用于接收前端参数 ├── vo # 视图对象，用于返回前端展示数据 ├── config # 配置类，如MybatisPlus、跨域、拦截器 ├── common # 通用返回结果、异常处理、常量 ├── utils # 工具类 └── annotation # 自定义注解

核心原则就是：Controller不写业务逻辑，Service只处理业务，SQL封装在Mapper层。这样做的好处是，每个类的职责单一，出了问题能快速定位。面试官问你“如果报表统计很慢，你怎么排查”，你能直接说先从SQL入手看Mapper的查询计划，这就是分层带来的底气。

3. 数据库设计与核心表结构

3.1 从业务反推数据库表

数据库设计是整个项目最见功力的地方。如果表设计烂，后面无论怎么写代码都会感觉很别扭。我是按业务流程推出来的表。

先列一份完整的表清单：

表名	作用	备注
sys_user	用户表	四类角色共用
sys_role	角色表	管理员、辅导员、企业、学生
sys_user_role	用户角色关联表	多对多关系
edu_college	学院表	基础数据
edu_major	专业表	关联学院
edu_clazz	班级表	关联专业
job_info	升学就业信息表	企业/院校发布
job_category	信息分类表	如国企、升学、实习
volunteer_application	志愿申报表	核心表
volunteer_audit	志愿审核记录表	审核留痕
admission_result	录取结果表	与志愿申报一对一
sys_operation_log	操作日志表	审计需要

这里重点说明三个核心设计。

用户表：不分成“学生表”“企业表”“管理员表”三张，而是用一张sys_user存登录账号、密码、手机号、姓名、类型字段，再通过user_type区分角色。这样登录认证只需要查一张表，后面用Spring Security或者自定义拦截器做权限控制时，逻辑链路很短。学生的专业班级信息，我单独用student_profile表去关联，避免用户表字段过于臃肿。

志愿申报表：这是整个系统的核心。一个学生可以报多个志愿，但同类型、同批次下不能重复，这个约束没法只在数据库层面靠一个唯一索引搞定，需要在业务层做校验，同时配合事务。表里最关键的状态字段status我用int存储，1待审核、2审核通过、3已驳回、4已录取、5已放弃，状态流转全部通过编码控制，不用字符串，避免出现“待审核”、“审核中”、“已审核通过”这种乱写的情况。

录取结果表：用admission_result与volunteer_application做一对一关联，虽然也可以在志愿表上加一个录取字段，但单独建表的好处是：可以记录录取时间、录取操作人、录取批次、是否公示等额外信息，统计录取率时也只需要查这一张表，不用去过滤志愿表的历史状态。

3.2 核心表字段设计细节

以volunteer_application为例，字段设计如下：

字段名	类型	说明
id	bigint	主键，雪花算法生成
student_id	bigint	学生用户ID，关联sys_user
job_id	bigint	升学就业信息ID，关联job_info
volunteer_type	tinyint	志愿类型：1就业、2升学
priority	int	志愿优先级，1为第一志愿
status	tinyint	1待审核 2通过 3驳回 4录取 5放弃
audit_comment	varchar	审核意见
audit_time	datetime	审核时间
create_time	datetime	填报时间
update_time	datetime	更新时间
deleted	tinyint	逻辑删除标记

几个容易被忽略的细节：

主键我用的是MyBatis Plus的ASSIGN_ID雪花算法，不用数据库自增。好处是分表分库友好，而且插入前就能拿到主键，方便处理关联逻辑。
create_time和update_time用MyBatis Plus的自动填充注解@TableField(fill = FieldFill.INSERT)，配合MetaObjectHandler，不需要每段代码手写时间赋值。
deleted逻辑删除，加在每张业务表上。用户误删志愿、企业误删信息时，实际上只是update deleted字段，这样历史数据可以追溯。

3.3 索引设计与查询优化

表设计出来之后，我一定会检查每个高频查询条件。项目里最高频的三类查询是：

学生查我的志愿列表：where student_id = ? and deleted = 0，所以给student_id建普通索引。
企业查某条招聘信息下所有申报学生：where job_id = ?，给job_id建索引。
首页分页搜索：where status = ? and category_id = ? order by create_time desc，这里建联合索引(status, category_id, create_time)。

索引设计最忌讳“每个字段都加索引”，因为索引不是免费的，插入和更新都要同步维护B+树。我的习惯是：先用慢查询日志或者执行计划EXPLAIN，看看哪些SQL走了全表扫描，再针对性加索引。比如候选人筛选时，如果发现job_info表在status字段上没有索引，查询要扫描全部已发布信息，那果断加上。

4. 志愿填报与录取管理的业务流程实现

4.1 就业信息发布的审核机制

企业发布的招聘信息不能直接上架展示，这是业务规则。原因很简单：防止企业乱发广告，保证信息质量。所以在job_info表中，我设计了一个status字段，0草稿、1待审核、2已发布、3已下架、4审核驳回。

管理员审核时，其实是更新状态并记录操作日志。这里有个小技巧：审核驳回时，必须填写驳回原因，并且把这个原因通过站内消息或者待办提醒推送给企业用户。我在job_info表里加了audit_comment字段，配合一个简单的通知记录表，实现了最基本的“审核不通过原因可见”。虽然功能不大，但体验感和完整性明显不一样。

4.2 志愿申报的完整状态流

志愿申报是整个系统最有业务深度的部分。我把它设计成五个状态，任何一个状态变化都伴随具体业务动作：

待审核：学生提交志愿申报后，系统自动把志愿推送给该学生所属学院/专业的辅导员。
审核通过：辅导员确认学生符合申报资格，志愿进入企业端可见列表。
审核驳回：辅导员填写原因，学生可以修改后重新提交。
已录取：企业在通过审核的名单里选择录取，系统自动给其他未录取学生的该志愿标记为淘汰并不再进入后续流程。
已放弃：学生声明放弃录取资格，系统释放该岗位名额。

代码实现上，我写了一个VolunteerStateMachine工具类，统一管理状态切换。核心方法是transition(currentStatus, targetStatus, operatorRole)，内部维护一个合法的状态流转Map。非法操作直接抛业务异常，返回友好提示。这样有效杜绝了“学生绕过审核直接把志愿改成已录取”这类逻辑漏洞。

4.3 并发场景下的重复提交问题

开发测试单体项目的时候，一般不会出并发问题。但一旦部署到服务器上，前端用户同时点“提交志愿”，后端就可能出现同一名学生同一时间提交两条相同志愿记录。

解决方式不能只靠前端禁按钮，后端必须要做兜底。我用两个手段：

数据库层：给student_id + job_id + volunteer_type加联合唯一索引。这个索引能保证即使是并发请求，数据库也只会成功插入一条。
业务层：在Service中，插入之前先查一遍是否已有相同记录，结合事务的隔离性，做到重复请求返回“志愿已提交”。

如果想把并发安全做得更精细，可以用Redis的setNx做一个简单的分布式锁，锁的key设计成volunteer:apply:{studentId}:{jobId}，获取不到锁就说明正在处理中。这个点放在简历里，属于“解决了并发重复提交问题”，面试官会比较认可。

4.4 录取统计与公示

录取结果生成之后，系统要能按学院、专业、班级统计填报率和录取率。统计的SQL我直接用group by聚合，没有额外建统计表，因为数据量在毕设场景下很小，实时统计完全扛得住。

核心SQL大概长这样：

SELECT m.major_name, COUNT(DISTINCT v.student_id) AS apply_count, COUNT(DISTINCT a.student_id) AS admitted_count FROM volunteer_application v LEFT JOIN admission_result a ON v.id = a.volunteer_id AND a.`status` = 1 JOIN student_profile sp ON v.student_id = sp.user_id JOIN edu_major m ON sp.major_id = m.id WHERE v.create_time BETWEEN #{startTime} AND #{endTime} GROUP BY m.id

统计结果用Hutool的ExcelWriter导出，几行代码就能生成xlsx文件。这个功能写进论文里，可以标注为“系统提供多维数据导出能力”，属于亮点功能。

5. 智能推荐：从简单关键词匹配到多维度排序

5.1 推荐的需求与算法选型

标题里既然写了“智能服务系统”，那纯做CRUD肯定是不够的。我加入了推荐逻辑：学生登录后，首页不只展示所有信息，而是优先展示“可能适合该学生的职位/升学计划”。

最经典的实现是基于内容的推荐。逻辑很简单：把学生的画像（专业、意向城市、意向岗位类型、技能标签）和职位画像（岗位名称、岗位要求、薪资范围、工作地点）做匹配打分，按分数降序排列。这种方法在数据量不大的场景下效果不错，而且可解释性强——页面上可以直接标注“推荐理由：岗位要求与你的Java后端开发技能匹配度较高”。

5.2 关键词提取与相似度计算

关键词匹配我用的是TF-IDF的简化版。不引入复杂的分词库，而是维护一个岗位技能标签表，提前把岗位描述里的高频词提取出来，比如“Java”、“Spring Boot”、“MySQL”、“Redis”、“Linux”、“项目管理”。

学生的画像里，我也设计了一个skills字段，学生注册或修改简历时，从标签库中选择自己的技能。这样计算匹配度时，就是两个集合做交集，不需要笨重的文本相似度计算。

5.3 推荐评分公式与参数计算

推荐评分我用了一个多因子加权公式：

score = w1 * 技能匹配度 + w2 * 专业契合度 + w3 * 意向城市得分 + w4 * 薪资适配度 + w5 * 发布时间衰减因子

我实际定的权重是w1=0.4, w2=0.25, w3=0.15, w4=0.1, w5=0.1。每个因子归一化到0到1之间。

举一个实际计算的例子：某岗位要求Java、MySQL、Spring Boot，学生技能匹配了Java和MySQL，那么技能匹配度 = 2/3 ≈ 0.67；学生专业是计算机科学与技术，岗位对应的专业类别包含该专业，专业契合度=1；意向城市是杭州，岗位地点是杭州，城市得分=1；岗位薪资15K，学生期望薪资10K到15K之间，薪资适配度=0.9；发布时间是3天前，衰减因子按公式1 / (1 + log(1 + days))计算，约等于0.88。

最后得分 = 0.4 * 0.67 + 0.25 * 1 + 0.15 * 1 + 0.1 * 0.9 + 0.1 * 0.88 = 0.268 + 0.25 + 0.15 + 0.09 + 0.088 = 0.846。

排序之后，系统优先展示得分高的岗位。这个算法虽然比不上机器学习模型，但它完整、可解释、可落笔写进论文，而且面试官如果想深挖，你能把公式和参数说明白，就已经超过大部分毕设项目了。

5.4 推荐结果的落地

推荐结果我并不是每次实时计算，而是在学生修改简历或技能标签时，触发一次异步计算，把推荐结果列表缓存到Redis里，key是recommend:student:{studentId}，有效期24小时。这样首页打开速度非常快，不会因为算推荐导致接口响应变慢。

前端拿到推荐列表后，每条数据上会显示一个“推荐指数”的进度条，这个数值就是上面算出来的score的百分制展示。页面交互很轻，但整体感觉非常像一个真正在运营的系统。

6. 权限控制、安全防护与审计

6.1 基于角色的访问控制

四类角色的权限差异很大，我用RBAC模型控制。在Spring Boot里，我实现了两个层面：

接口层面：自定义@RequireRole注解，放在Controller方法上，通过拦截器判断当前用户角色。比如企业录取操作只允许企业角色调用。
数据层面：业务查询时，根据当前登录用户的ID和角色，拼接额外的查询条件。比如辅导员只能查自己所在学院或专业的数据。

用Spring AOP也可以实现类似功能，而且AOP的动态代理机制在Java面试里经常被问到。我当时是用自定义注解 + Spring AOP做了操作日志记录，把核心业务方法的入参、执行结果、耗时统一记录到sys_operation_log表。这样既实现了审计需求，又能在面试时讲明白“动态代理在实际项目中的应用”。

6.2 JWT登录态与接口鉴权

登录认证我用JWT而不是传统的Session。前后端分离的项目，用JWT天然合适：服务端不存登录态，客户端请求时在请求头带上Authorization: Bearer token，服务端验签后解析用户信息。

JWT的坑在于退出登录失效问题。我做了两层补偿：一是Redis里存了一份token的黑名单，用户主动退出时把token拉黑；二是把token的有效期设置为2小时，并支持refresh_token刷新，防止长时间操作时突然掉线。

String token = JWT.create() .withClaim("userId", user.getId()) .withClaim("role", role.getCode()) .withExpiresAt(new Date(System.currentTimeMillis() + 2 * 60 * 60 * 1000)) .sign(Algorithm.HMAC256(secretKey));

6.3 SQL注入、XSS防护与密码存储

安全问题虽然毕设不强制，但一定要做，因为这在面试中属于“亮点分”。

密码我用的BCrypt加密，不用MD5。MD5是散列算法，不是为密码设计的；BCrypt内置盐值，同一密码每次加密结果都不一样，暴力破解难度大。
SQL注入主要靠MyBatis Plus的预编译机制，尽量不拼SQL字符串。如果必须写自定义SQL，一律用@Param+#{}占位，不用${}。
XSS防护在前后端同时做。后端的核心接口对提交的字符串做HTML标签清洗，把<script>转义成<script>，避免存储型XSS。

7. 实操过程中的常见坑与排查实录

7.1 数据库事务不生效

我最早写的提交志愿方法，直接在Controller层调了两次Mapper的insert，没有加@Transactional。结果测试的时候故意让第二次插入报错，发现第一条数据居然提交成功了。原因很简单：Spring的事务是通过AOP代理实现的，只有跨过代理的public方法，事务才会生效。事务方法不能是private，也不能被本类内部通过this调用。

正确写法是拆一个独立的Service方法，加上@Transactional(rollbackFor = Exception.class)，在Controller里调用。rollbackFor一定要指定，否则默认只在RuntimeException时回滚，受检异常不会触发回滚。

7.2 日期时间格式化问题

前端传2025-05-20 14:30:00，后端用@RequestBody接收时，LocalDateTime字段经常报反序列化错误。解决方式是在application.yml里统一配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

但这里有个坑：spring.jackson.date-format只对java.util.Date生效，对LocalDateTime不生效。LocalDateTime需要单独加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")注解，或者全局配置Jackson的JavaTimeModule。我最后是写了一个JacksonConfig，统一注册了LocalDateTime的序列化器和反序列化器，再从MVC的Converter层面兜底处理，这样所有前端传参和返回都统一走这一套，不会再出现某个接口时间格式不对的问题。

7.3 慢SQL与索引失效

项目联调阶段，企业端的申报列表页很慢。我用EXPLAIN看了执行计划，发现SQL里对job_info.create_time做了DATE(create_time) = '2025-05-20'的查询。DATE()函数包住了索引列，导致索引失效，全表扫描。

改成范围查询create_time >= '2025-05-20 00:00:00' AND create_time < '2025-05-21 00:00:00'，索引就正常走了。这类隐式转换和函数包裹索引列的问题，在真实项目里非常常见，遇到慢SQL先执行计划，80%能定位到原因。

7.4 前端跨域与联调问题

前后端分离最大的联调障碍就是跨域。我在后端写了一个CorsConfig，允许本地开发端口访问：

registry.addMapping("/**") .allowedOriginPatterns("http://localhost:*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true);

注意allowedOriginPatterns和allowedOrigins的区别，如果使用allowCredentials(true)，那么allowedOrigins不能用*，而要用模式匹配，否则浏览器会拒绝带cookie的请求。虽然我用的是JWT不依赖cookie，但统一把配置写对，省得后面踩坑。

7.5 部署上线与工程化

项目打包我用Maven，执行mvn clean package -DskipTests，生成jar包，上传到服务器后用nohup java -jar xxx.jar &启动。如果服务器内存小，记得加JVM参数限制内存：

nohup java -Xms256m -Xmx512m -jar volunteer-system.jar --spring.profiles.active=prod > app.log 2>&1 &

有条件的话，可以引入Jenkins做简单的持续集成。Jenkins上配置一个Maven项目，代码推送到Git仓库后自动拉取、编译、打包、重启服务，整个流程十几分钟就能配好。面试时提到“我用Jenkins做过自动化构建部署”，这又是一个加分项。

8. 结束前的一点补充

最后说一个我自己做这套系统时感触很深的点。一开始我也只想着把功能写完，代码能跑就行。但后来发现，真正让这个项目从一个“作业”变成一个“作品”的，恰恰是那些别人不容易看到的地方：状态机的设计、并发重复提交的处理、JWT的安全细节、慢SQL的排查、部署时的JVM参数优化。这些点单独拎出来都不算大功能，但组合在一起，才是一个完整的、真正能交付的系统。

如果你现在也正在做类似的Java毕设项目，我给的建议是：不要只盯着“能用”，要多问自己几个为什么——为什么这个状态要这么流转？为什么这里要加索引？为什么事务要放在这一层？当你把这些问题想清楚，答辩和面试都不再是背书，而是真的在讲自己做过的东西。这套系统后面如果要扩展，可以考虑接入消息队列做企业端待办通知，或者把推荐算法换成更灵活的Embedding；但在此之前，把已经写完的代码再优化一遍，把核心业务的边界想透，往往收获比新加一堆花哨功能要大得多。