基于SpringBoot的勤工俭学系统：毕业设计实战与答辩全攻略

每年到三月，我这边就会密集收到一类私信：学长，计算机毕业设计到底选什么题？SpringBoot的题目是不是烂大街了？然后聊到最后，总会有人补一句，"有没有那种功能看着不low、工作量适中、答辩还不会被问住的题目？" 如果你也有同样的需求，那基于SpringBoot的勤工俭学系统，确实是值得认真考虑的一个选择。

这不是我空口推荐。勤工俭学系统这个方向，表面看就是一个常见的"XX管理系统"，但真正把它拆开，它覆盖了用户角色权限、岗位发布与申请、工时登记与审核、按月结算工资、统计报表这整条业务链路，既有增删改查的标准操作，又有状态机流转和金额计算这种可以深挖的技术点。用它来做计算机毕业设计，既不会像"学生信息管理系统"那样被答辩老师一句话问穿，也不会像"大型电商系统"那样超出本科毕设的工作量边界。

这篇文章，我打算把整个项目从选题定位、技术选型、数据库设计、核心功能实现，到最后的论文写作和答辩准备，完整走一遍。我不会只给一张截图式的功能清单，而是把所有决定"为什么这么做"的判断逻辑也交代清楚，这也是我带毕业设计这几年下来，觉得同学们最缺的东西。

1. 为什么这个"勤工俭学系统"恰好是毕设的黄金选题

1.1 业务闭环完整，全流程都有内容可写

很多同学选题子容易走两个极端：要么业务太简单，比如"班级通讯录管理系统"，做完就是一个通讯录增删改查，论文写到第三章就没话了；要么业务太复杂，比如"分布式秒杀系统"，光压测和一致性方案就能让你怀疑人生。

勤工俭学系统的业务复杂度和本科毕设正好匹配在一条线上。完整的业务流是这样的：管理员在后台录入用工单位的勤工俭学岗位，学生登录系统浏览岗位并提交申请，用工单位或管理员审核申请，审核通过后学生开始登记每日工时，管理员按月对这些工时进行核定，最后系统根据核定工时和岗位时薪自动生成工资结算单。

这条链路覆盖了一个真实业务系统的完整闭环，每一个环节都有对应的表、接口和页面。写论文的时候，需求分析不愁没素材，系统设计不愁没图可画，数据库设计不愁没表可列。答辩老师问"你这个系统的核心业务流程是什么"，你可以把这个闭环说得非常连贯，因为他问什么，你都有实际功能在支撑。

1.2 综合考察点刚好命中毕设评分表

一个看起来功能清晰的业务系统，实际上把所有常见的毕设评分点都覆盖了：

• 多角色权限管理：学生、用工单位、管理员三种角色，对应不同的菜单和数据权限，这正是"系统设计能力"的加分区域。
• 核心业务状态控制：岗位申请要从"待审核"流转到"已通过/已驳回"，在岗后还有"离岗"状态，这是状态机设计的最佳实践。
• 时间与金额的边界校验：工时登记不能重复、不能超过岗位规定的月度上限，结算金额必须精确到分，这里能聊的内容远比你想象得多。
• 报表统计：按学院、按月统计参与人数和工资支出，这种图表展示是答辩环节的"可视化亮点"。

这么说吧，一个勤工俭学系统能讲出来的设计点和普通的管理系统不是一个层级。它是"带业务规则的管理系统"，而不只是"数据库换皮"。

1.3 演示起来直白，非技术视角也看得懂

毕设答辩的时候，评委并不全是搞Java的，但几乎所有评委都能理解"勤工俭学"这个业务场景。学生申请岗位、确认上岗、填写工时、发工资，这一串动作不需要任何背景解释，演示五分钟，评委心里已经对系统有了基本判断。

这对答辩非常有利。很多同学做了一个技术很强但业务冷门的题目，演示到一半评委还在问"你这个场景是干嘛的"，注意力已经完全不在系统上了。勤工俭学系统不需要你花大篇幅铺垫教育背景，直接演示功能，评委能看懂你在做什么，自然能顺畅地问到技术点上。

2. 技术选型遵循的三条原则：稳、熟、有的讲

2.1 后端框架版本：在"稳定"和"不老气"之间找到平衡

先给结论：Java 8 或 11 + Spring Boot 2.7.x，这个是当前毕设圈最稳妥的组合，没有之一。

Spring Boot 3.x 虽然已经发布很久了，但它要求 Java 17 起步，部分老网上的博客代码、你学长留下的参考资料，很多还是基于 Spring Boot 2.x 写的。毕业设计周期就那么几个月，没必要用自己的查错时间给新版框架当陪练。Spring Boot 2.7 还在维护期，支持范围广，网上能搜到的问题和解法数量最多，这是它最大的优势。

有人会纠结"题目叫基于SpringBoot，我用2.7.x会不会显得技术旧"，实际上不会。Spring Boot 2.7 是一个庞大存量项目使用的版本，论生产环境占有率它仍然非常高。答辩老师更关心的是你对框架的理解，而不是版本号。如果你在论文里写"为什么没有盲从最新版本"，反而是个加分的判断力体现。

2.2 数据访问层：MyBatis-Plus是当前最优解

数据访问层，我几乎不用犹豫就推荐 MyBatis-Plus 3.5.x。理由有三点：

第一，它的代码生成器和通用Mapper能极大减少重复单表CRUD代码，把时间留给核心业务。第二，它的分页插件、乐观锁插件都是现成的注解导入就能用，写进论文里是非常清晰的"技术亮点"。第三，国内毕业设计能找到的参考代码绝大多数基于MyBatis或MyBatis-Plus，遇到问题你能查到的资料量级完全不同。

JPA在国外教程里用得非常多，但在国内毕设语境下，JPA的复杂关联映射和"懒加载序列化报错"这些问题，会让一个本科生的开发体验迅速恶化。我不是说JPA不行，而是从"毕业设计按时交付"这个目标出发，MyBatis-Plus更合适。

2.3 权限认证：JWT + 拦截器/Spring Security，二选一

很常见的一个场景是，同学一上来就问我"学长，权限认证是不是必须用Spring Security？"

我的看法是：用，但不一定要"全家桶"式地硬上。如果你整个系统只有简单的角色判断，直接基于JWT + 拦截器实现，为每个接口通过注解标注需要的角色权限，代码量不大，逻辑非常直观，答辩也好解释。

如果你对自己Spring Security的掌握有信心，那用它 + JWT 的确是最标准的方案，也更容易体现技术深度。问题在于Spring Security的过滤器链和配置项非常多，一旦某个权限表达式写错，排查周期可能拖到三到五天，这个时间成本在毕业设计的倒计时里往往付不起。

选型建议：时间充裕、想冲刺高分的用Spring Security；想求稳预算有限、把精力花在业务闭环上的用Sa-Token或自定义JWT拦截器。两种方案都能讲出道理，不会被认为"技术不足"。

2.4 前端方案：有基础就Vue3前后端分离，没基础就用服务端模板

前端部分，理想的搭配是Vue3 + Element Plus + Vite，通过前后端分离的方式架构，这也是近几年毕设的主流方案。前后端分离的好处是项目结构清晰、接口文档完整，答辩时可以明确说"前端通过RESTful API与后端交互"，这个表述本身就是一个技术得分点。

但是要泼一盆冷水：如果你JavaScript基础本来就很薄弱，从来没有独立写过Vue项目，我不建议在毕设阶段临时搞前后端分离。我曾经见过一个同学，数据库和后端已经全部搞完，结果花了两周时间卡在Vue的路由和跨域上，最后熬夜推翻重来。

这种情况下用Spring Boot的Thymeleaf模板引擎，配合Bootstrap或者国内的一些后端管理模板，一样能做出一套功能完整的系统。技术点照样可以写"采用Thymeleaf服务端渲染，通过拦截器控制页面访问权限"。形式不同，工作量不同，但业务功能一分不少。

3. 数据库设计：六张表把业务闭环撑起来

3.1 角色建模：三类用户的共性与差异

很多毕业设计一开始就在用户表上犯难：学生和用工单位差别很大，是不是要做两张表？

正确做法是建立一张用户表，通过role字段区分角色，然后为个性化信息单独建扩展表。比如用户表存username、password、realName、phone、role这些公共字段，StudentInfo表存学号、学院、专业、年级，用工单位如果字段不多也可以直接在用户表加 companyName、creditCode。

这样设计的好处有两个：登录认证只需要查一张表，逻辑简单；论文里画权限分析时，"一个系统用户，三种角色"的表述非常清晰。如果你已经有了spring security或Shiro基础，这种通用的UserDetails模型也更贴合框架的设计思路。

3.2 核心表结构与字段设计

完整项目至少需要六张核心表。下面我直接给出我在类似项目中常用的字段设计，你可以直接抄进数据库设计文档：

这套设计里有两个容易出彩的细节。第一，job_position里冗余了 applied_count 和 working_count 两个数字字段，虽然它们可以用count查询实时统计，但冗余字段在列表页展示时能少一次多表联查，答辩时你可以主动讲"这是用空间换时间的经典做法"——这个细节就比普通的设计高一个身位。第二，salary_settlement里冗余了 hourly_rate，因为岗位时薪未来可能调整，结算单必须保留结算当时的时薪快照，否则历史账目会跟着新时薪变掉，这是典型的"字段快照设计"。

3.3 关键约束：如何防止学生重复在岗

业务上有个硬性规则：一个学生同时只能在一个勤工俭学岗位上工作。如果只靠代码判断，并发情况下很容易出现两个申请同时通过了校验，最后学生同时出现在两个岗位上。

数据库层面的解法是：在job_apply表上增加一个is_active字段，1表示当前存在有效在岗关系，0表示历史记录。然后建立唯一索引uk_student_active(student_id, is_active)，因为同一学生 is_active=1 的记录最多只能有一条，数据库会在源头就挡住重复在岗。

这个设计在论文里值得大写特写：数据库约束兜底 + 业务代码校验双重保障，采用软删除/标记位方式保留完整历史。这种"从数据库设计层面解决并发问题"的表述，答辩加分效果非常明显。

3.4 字段类型的几个隐藏小坑

时间字段全部用datetime，不要用timestamp，因为timestamp有时区转换问题，不同环境部署可能出现8小时偏差，到时排错你根本想不到是这个原因。

金额字段务必用decimal(10,2)，不要用float或double，二进制浮点数在金额计算上会产生的精度误差在工资系统里是硬伤。后面我会单独讲这个问题。

工时字段如每日工时建议用decimal(4,1)，允许0.5小时的粒度，也保留扩展0.25小时的可能，这比int更贴合真实考勤场景。

4. 四个核心功能的实现思路与代码长啥样

4.1 登录认证与角色权限控制

不管用哪套权限框架，你要做清楚的其实就三件事：登录时签发令牌，请求时解析令牌识别身份，访问接口时校验角色。

如果用JWT + 拦截器的轻量方案，核心逻辑大致长这样。用户登录成功后，用用户ID和角色生成一个带过期时间的JWT令牌返回给前端；前端在请求头Authorization: Bearer xxx里带上令牌；后端写一个拦截器统一解析令牌，然后把用户信息放到ThreadLocal上下文里。

接口的角色控制用自定义注解做最简单：

@Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String[] value(); }

然后在拦截器里校验当前登录用户角色是否在注解允许列表里。这样做的好处非常具体：每个接口需要的权限写在方法上的注解里，一眼就能看出来，论文里可以配一张"接口权限矩阵表"，老师看了就觉得你系统设计很不错。

4.2 岗位申请的状态流转：不要写if嵌套地狱

岗位申请是整个系统状态最丰富的模块。我遇到过不少学生，写状态流转就是用一堆if判断：

if (apply.getStatus().equals("待审核")) { if (action.equals("通过")) { apply.setStatus("已通过"); } }

这写法在状态少的时候没问题，但岗位申请至少要经历：待审核、已通过、已驳回、已撤销、在岗中、已离岗这六种状态，每次流转还有角色限制。堆if会让代码迅速失控，也无法写清业务规则。

更好的做法是建一个状态流转校验逻辑，用一个Map维护状态之间的合法转换关系：

private static final Map<String, List<String>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put("PENDING", Arrays.asList("APPROVED", "REJECTED", "WITHDREW")); TRANSITIONS.put("APPROVED", Arrays.asList("WORKING", "TERMINATED")); TRANSITIONS.put("WORKING", Arrays.asList("TERMINATED")); }

然后写一个统一的方法在每次更新状态前校验：当前状态和目标状态是否在同一组"起止对"里，并且校验执行操作的人是否拥有该流转权限。这样状态流转的规则变成了可以被审查的数据结构，而不是散落在各处的if。这个设计思路也可以替换成一个状态枚举类。

数据库层面，状态字段用varchar存英文枚举值（PENDING、APPROVED），展示层再翻译成中文。不要在数据库里存中文状态，原因是查询排查、扩展新状态时中文会产生大量额外工作。

4.3 工时登记：防重复、防超量、留审核空间

工时登记模块最容易出问题的地方在"重复登记当天工时"和"超额登记月度工时"。学生一天只能给当前岗位登记一次工时，月度累计工时不能超过岗位设定的 max_hours 上限。

代码里需要两步校验：第一步，查当天是否已存在该学生的工时记录，如果存在则拒绝；第二步，统计本月已核定或待核定的工时总和，加上本次登记数值后，与岗位上限做比较。注意，这两步在分布式并发场景下都会有竞态问题，但毕设通常并发量不大，可以通过数据库唯一索引 + 业务校验双保险来兜底：

-- work_log表对(apply_id, work_date)建立唯一索引 ALTER TABLE work_log ADD UNIQUE uk_apply_date (apply_id, work_date);

工时的审核流程也需要注意：学生提交工时记录后，默认状态为PENDING，由管理员在月末统一核定，核定通过后该条工时才计入结算总额。这个流程设计比"学生填了直接生效"要真实得多，也是业务逻辑上能讲深的地方。

4.4 月度工资结算：定时任务加快照

工资结算是把整条业务链闭合起来的关键，建议用Quartz或Spring自带的@Scheduled实现一个定时任务：每月1日凌晨，系统自动扫描上个月所有核定通过的工时记录，按学生维度汇总，并按每个学生当前岗位的时薪快照生成工资结算单。

用Spring自带的定时任务就能满足需求，核心逻辑是在查询时组装月份条件：

@Scheduled(cron = "0 0 1 1 * ?") // 每月1日凌晨1点执行 public void generateMonthlySettlement() { String lastMonth = LocalDate.now().minusMonths(1) .format(DateTimeFormatter.ofPattern("yyyy-MM")); // 查询上月核定通过的工时记录，按学生分组汇总 // 生成结算单并插入salary_settlement表 // 校验同一学生同一月份只能有一条结算单，靠唯一索引兜底 }

人工重跑也需要考虑：如果因为某个月份定时任务执行失败了，管理员可以从后台手动触发补结算，或者提供"重新生成"按钮。这套兜底机制写进论文，就是"系统可靠性设计"的素材。

金额计算部分，所有工资相关的计算结果必须用BigDecimal，禁止直接double相乘：

BigDecimal totalSalary = totalHours.multiply(hourlyRate) .setScale(2, RoundingMode.HALF_UP);

5. 带毕业设计最常见的五个翻车现场及根治方法

5.1 LocalDateTime返回前端少了8小时

这是SpringBoot项目里最经典的坑，没有之一。数据库存的是标准时间，Jackson序列化时使用了美国时区，导致前端看到的时间比实际时间少8小时。

根治方法是在配置文件里固定Jackson时区：

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

同时数据库URL上也要带上时区参数：

jdbc:mysql://localhost:3306/workstudy?serverTimezone=Asia/Shanghai

这两个地方任何一个漏了，时间就会出现诡异偏差。这个坑很具代表性，答辩可以主动跟老师分享"排查时区问题的过程"，算是真实排障经验的展示。

5.2 BigDecimal和double的精度灾难

学生登记了2.25小时工时，时薪每小时20元，double计算结果是45.0，看着没毛病；但如果工时是2.1小时，时薪19.9元，double算出来可能是41.790000000000006，存进数据库四舍五入还好，一旦落在某个中间计算流程里就是明显的数据错误。

工资系统里所有涉及金额的地方，一律BigDecimal。BigDecimal构造时特别注意，要使用字符串构造器new BigDecimal("19.9")，不要用new BigDecimal(19.9)，后者依然会有二进制浮点数的精度干扰。这条规则必须写进代码规范里，并作为答辩的一个知识点准备好。

5.3 MyBatis-Plus乐观锁插件配置了却失效

很多同学做"工资结算"或"审核工时"时为了防止并发修改，会加 @Version 乐观锁。配置了却没有生效，常见原因是少配了拦截器：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor()); return interceptor; } }

而且注意两条硬性规则：第一，乐观锁字段必须有 @Version 注解；第二，执行update时必须通过实体对象传入带版本号的记录，不能只传一个主键id。这两个细节任何一个没做到，乐观锁都会悄悄失效，一点报错提示都不给你。

5.4 多表联查分页，count总是出错

MyBatis-Plus的分页插件本身挺好用，但一旦业务查询里出现多张表的JOIN，自动生成的count SQL可能不准确，甚至直接报字段找不到。典型场景是"岗位管理分页列表"要联查用工单位名称、已申请人数，然后分页就翻车了。

处理方法有两种：第一种是手动写count优化，把复杂的count SQL单独覆盖，保证只查主表；第二种是MP版本里增加jsqlParser依赖，让MP能对count SQL做更精准解析。多数情况下，加上jsqlparser依赖就能解决。这个报错信息非常隐晦，开发中容易卡上一整天。

5.5 学生重复申请同一个岗位

如果数据库没有uk_student_active(student_id, is_active)这类唯一约束兜底，学生在页面快速点两下"申请"，或开了两个标签页同时提交，后端可能产生两条状态都是待审核的申请记录。

我在3.3节提到过这个方案。再补充一点，业务代码里的先查后插只能降低风险，不能根除并发问题。唯一的根治方案是数据库约束。答辩时，如果你能说出这句话，评委对你的系统设计的评价会明显不一样。

6. 论文与答辩：把这些细节准备好，不容易被问住

6.1 论文各部分写作顺序，别从第一章按顺序写

很多同学写论文从绪论开始，写两周还在绪论里出不来。正确的路线是：先搭好架构图、ER图、核心表结构，这些内容明确了，需求分析和系统设计的章节就非常好写；然后是开发完毕后的功能截图和核心流程截图；最后回头补绪论和国内外现状。

需求分析章节的价值在于"用例图加文字说明"，每个角色一张用例图，配合每个用例的描述表格。这个工作量不算大，但能直接把系统设计的说服力拉满。

系统设计章节是论文的重头戏，要有系统架构图和功能结构图，并配上数据库完整ER图。注意，图上所有表之间的关系必须与代码里实际使用的字段一致，否则答辩老师随意指一张表问你字段含义，你卡壳就得不偿失了。

6.2 答辩展示脚本要设计成"打怪通关"式

演示不要想到哪点到哪，按业务闭环走一遍是最好的主讲方式：

• 第一步：用学生账号登录，浏览岗位列表，搜索并申请一个岗位
• 第二步：切换到管理员账号，在审批中心通过申请，顺手展示一个被驳回的申请作为对照
• 第三步：回到学生账号，登记当天工时
• 第四步：切换管理员，进行工时核定和月度结算，展示生成的结算单
• 第五步：打开统计报表页面，展示按月、按学院的图表

整个过程就是一个完整的故事链。答辩气氛通常比较紧张，有了剧本，即使脑袋空白也能靠肌肉记忆走完流程。

6.3 预先准备好系统的薄弱点"防御话术"

答辩时评委最喜欢从一个不常展示的功能切入。提前问自己几个问题：岗位下架后已申请的记录怎么处理？学生被禁用后未结算的工资怎么办？时薪调整了新老岗位如何对应？

每个问题你至少要准备一个能自圆其说的答案，哪怕你的实现确实不完美，也要能说清"目前这样设计的原因"。比如"岗位下架后我们会终止新的申请，但已经审核通过的申请仍然保持有效，直到岗位到期或主动终止"，这种答案比"这个功能我没做"强一万倍。

答辩评委普遍不是来为难你的，他们要验证的只是"这个系统是不是你自己做的、你有没有理解自己的设计"。

一点个人带毕设的经验

每次带学生做这种系统，我的建议都是：数据库的初始化脚本一定手写一份，把测试数据的完整流程提前造好——至少要有两个岗位、分布在两到三个学院的学生，以及两个月以上的工时和结算数据。数据越接近真实，演示效果越好，论文截图也越养眼。数据库记得做一次完整备份放在网盘里，答辩前重装系统本来就不罕见，你总不希望跟老师共用一台电脑凭空多出两个小时的环境搭建风险。

勤工俭学系统的代码量、业务完整度、答辩表达空间三个维度都处在一个很适合本科毕业设计的位置。把数据库设计做扎实、把状态流转讲明白、把月结流程跑通，这套系统就是一份拿得出手的完整毕业设计成果。