简介毕设学生勤工俭学系统.zip 是一份面向高校毕业设计环节的完整Web应用项目适合计算机相关专业学生用于课程设计或毕业课题参考。项目围绕高校勤工俭学管理场景实现岗位发布、学生申请、工时记录、工资计算与双向评价等核心功能可用于理解校园服务类信息系统的完整开发流程涵盖需求分析、系统设计、编码实现、测试与文档编写等软件开发全过程要素。资源包共638个文件约6.6MB以gif动图、js脚本、html/jsp页面、java/class代码、jar依赖库为主另含css样式、db/mdf数据库文件、doc说明文档及辅助脚本基本覆盖从源码到运行环境的典型文件类型。目前已有1086人学习下载。压缩包同时提供asp、php等多语言文件与完整项目结构便于读者对照JSP实现方式进行比较学习对掌握MVC分层、Servlet处理请求、JDBC数据库交互及前端布局调试均有实际参考价值。1. 为什么毕设圈的勤工俭学系统值得你认真做一遍手上拿到「毕设 学生勤工俭学系统.zip」这个压缩包时很多人第一反应是解压看代码。但我建议你先别急着拆想清楚一个问题这套系统凭什么能当毕设题目。勤工俭学系统本质是典型的管理信息系统学生、用工部门、管理员三种角色串起一条完整业务链岗位发布、在线申请、工时填报、薪酬结算。它不像算法题那样拼模型效果评审更在意流程是否闭环、表设计是否合理、权限边界是否讲得清。选这个题的人大多是想用一套代码把 Web 全链路走通顺便在答辩时把每个表、每个状态机说透。这篇笔记我就按这个目标拆开讲。2. 把需求拆成实体用户、岗位、工时与结算的六张核心表2.1 三种角色与权限边界勤工俭学系统的业务闭环比图书管理多一层「结算」比宿舍管理多一层「审核」。先用角色把权限边界划清楚后面写接口才不会乱。常见做法是分三种角色学生负责浏览岗位、提交申请、填报工时、查看工资单用工部门负责发布岗位、审核申请、确认工时管理员负责用户管理、岗位兜底、月度结算和统计报表。权限边界在代码里怎么落毕设规模不需要引入重型权限框架用用户表的角色字段加前端路由守卫就够了。后端接口按角色校验前端按角色隐藏按钮两层都做才能算完整的权限闭环。我在模拟项目X里见过只做了前端隐藏、后端接口裸奔的翻车案例答辩时被追问一句「直接调接口怎么办」就卡住了。有人会纠结要不要拆成 user、student、department 三张表。我建议合成一张用户表加 role 字段理由有三登录逻辑统一、关联查询少一次 join、答辩讲 RBAC 概念更直观。部门名称等属性作为冗余字段放在用户表里只有管理员能看到角色为「用工部门」的用户记录。2.2 六张核心表的字段设计与关联表数量控制在六张以内既覆盖业务又不显得堆砌。这是我给这个题固定下来的清单字段只列关键项其余按常规补充即可。表名关键字段说明sys_userid, username, password, real_name, role, dept_name, statusrole 用 0/1/2 分别表示学生、部门、管理员job_positionid, title, description, dept_id, hourly_wage, headcount, recruited, status状态分招聘中、已满、已截止apply_recordid, student_id, job_id, status, apply_time状态分待审核、通过、拒绝work_logid, student_id, job_id, work_date, hours, status, confirm_time状态分待确认、已确认、驳回salary_settlementid, student_id, month, total_hours, total_amount, status状态分未发放、已发放announcementid, title, content, create_time公告表用于丰富页面和答辩素材几个字段设计的细节必须提前定好密码字段不能存明文用 BCrypt 加密长度给 60工时按 0.5 小时为最小颗粒度用 DECIMAL(4,1) 而不是 FLOAT免得 0.1 的精度问题让你在结算时抓狂金额统一 DECIMAL(10,2)所有涉及钱的字段都不许用 double。外键我建议只做逻辑关联不加物理外键理由在避坑章里细说。2.3 工时与薪酬的冗余字段结算口径在答辩前就要统一薪酬结算是这个系统的灵魂评审几乎必问工资是怎么算出来的。这里要定一条口径并在答辩时咬死某个结算月内学生所有「已确认」工时的汇总 — 每个岗位的时薪取该月最后一条确认记录的岗位时薪按岗位分别计算后求和。写成公式就是 月工资 Σ(岗位时薪 × 该岗位当月已确认工时)。salary_settlement 表里冗余 total_hours 和 total_amount 两个快照字段不是多此一举。岗位的 hourly_wage 随时可能被部门修改如果不做快照下个月查历史工资单时数值就漂移了这在财务上是不可接受的。同理核算结束并标记「已发放」后前端要把当月的工时填报入口锁掉不然数据越改越乱。这个冗余设计还能引出另一个答辩亮点结算时读取的是快照字段需要追溯明细时再按 month 关联 work_log 和 job_position。所以我在设计表时故意不加外键就是为了让快照能脱离岗位表独立存活。你把这个理由讲出来比单纯说「我建了外键保证一致性」要有说服力得多。3. 用 Spring Boot 把登录和岗位申请跑通JWT 与状态机3.1 工程结构与配置文件后端我选 Spring Boot 加 MyBatis-Plus原因很简单MyBatis-Plus 的单表 CRUD 不用写 SQL能把精力省给状态机和事务这些真正的核心逻辑。Spring Security 这个阶段没必要上一个拦截器加一个 JWT 工具类就能把权限说清楚答辩时也更容易对着代码讲。工程结构按职责分层别把所有类堆在一个包下。我一般会分成 controller、service、mapper、entity、common 五个包common 下放统一返回结果、JwtUtil、异常处理和拦截器。pom 里最关键的依赖就四个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependencyjjwt 0.9.1 是毕设圈最常见的版本网上资料多遇到问题好搜。MyBatis-Plus 版本别追新3.5.x 足够稳定。配置文件里除了数据源要把 JWT 的几个参数外置方便答辩时现场调过期时间。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/workstudy?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: 一串长度超过32位的随机字符串 expire-hours: 2 upload: path: /data/workstudy/files参数说明数据库连接串必须带 characterEncodingutf8 和 serverTimezone这两个不加中文乱码和时区报错会各坑你一次。jwt.secret 至少 32 位太短会报签名异常。upload.path 我直接指向项目外部目录理由在避坑章第 4 条展开。3.2 JWT 登录与拦截器三个类的核心代码登录接口走「校验用户名密码 → 生成 token → 返回用户信息」三步。密码校验用 BCrypt数据库里存的必须是加密后的密文绝不能明文。JwtUtil 是核心生成 token 时把 userId 和 role 塞进 claim后续接口全靠这两个字段做身份识别。Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire-hours}) private int expireHours; public String generateToken(Long userId, Integer role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expireHours * 3600 * 1000L)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody(); } }逻辑说明setSubject 存用户 IDclaim 里带角色这样拦截器解析一次 token 就能同时拿到身份和权限不用再查一次数据库。过期时间单位换算成毫秒别漏了 *1000L否则两个小时就变成两秒钟这是最常见的翻车点。登录 Controller 写出来很短但有个细节值得注意返回前把密码字段置空前端拿到用户信息里不该有密码密文这是安全习惯也是评审可能挑刺的点。RestController RequestMapping(/api/auth) public class AuthController { Autowired private UserService userService; Autowired private JwtUtil jwtUtil; PostMapping(/login) public Result login(RequestBody LoginDTO dto) { User user userService.findByUsername(dto.getUsername()); if (user null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } if (user.getStatus() 0) { return Result.error(账号已被禁用); } String token jwtUtil.generateToken(user.getId(), user.getRole()); user.setPassword(null); return Result.success(new LoginVO(token, user)); } }逻辑说明先查用户再验证密码两个条件合并判断避免用户名不存在和密码错误两种提示不一致导致信息泄露。status 字段做启用禁用这个字段在答辩演示禁用账号时很出效果。拦截器的核心是解析 token 并塞进 request 上下文后续接口从 request attribute 里取 userId 和 role。注意排除登录接口否则会出现「登录接口也要先登录」的死循环。Component public class JwtInterceptor implements HandlerInterceptor { Autowired private JwtUtil jwtUtil; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getMethod().equals(OPTIONS)) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { writeUnauthorized(response); return false; } try { Claims claims jwtUtil.parseToken(token.substring(7)); request.setAttribute(userId, Long.parseLong(claims.getSubject())); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { writeUnauthorized(response); return false; } } }拦截器里先处理 OPTIONS 预检请求这是前后端分离部署时最容易忘的一步。解析失败统一返回 401前端 axios 拦截到 401 就跳转登录页。注册拦截器时注意路径匹配/api/auth/login 和 /api/auth/register 这类匿名接口必须排除。3.3 岗位申请与审核状态机的接口设计岗位申请是并发压力最集中的地方也是答辩时最容易暴露问题的环节。业务规则有三条岗位状态必须是招聘中、已录用人数不能超过总人数、同一学生不能重复申请同一岗位。三条规则看着简单并发一上来就出事原因后面专门写。申请接口的事务逻辑要这样写先查岗位状态和人数再查重复申请记录校验通过后插入申请记录最后执行一条原子更新的 SQL 去累计已招人数。Transactional public Result applyJob(Long studentId, Long jobId) { JobPosition job jobPositionMapper.selectById(jobId); if (job null || job.getStatus() ! 0) { return Result.error(岗位不存在或已停止招聘); } Long count applyRecordMapper.selectCount( new LambdaQueryWrapperApplyRecord() .eq(ApplyRecord::getStudentId, studentId) .eq(ApplyRecord::getJobId, jobId) .ne(ApplyRecord::getStatus, 2)); if (count 0) { return Result.error(您已申请过该岗位); } int rows jobPositionMapper.increaseRecruited(jobId, job.getHeadcount()); if (rows 0) { return Result.error(岗位名额已满); } ApplyRecord record new ApplyRecord(); record.setStudentId(studentId); record.setJobId(jobId); record.setStatus(0); applyRecordMapper.insert(record); return Result.success(申请成功等待部门审核); }关键在 increaseRecruited 这条自定义 SQL它把「检查人数」和「增加人数」合并成一条原子操作。触发的条件用 recruited headcount 写在 where 子句里靠数据库行锁挡住并发而不是靠应用层的 if 判断。update idincreaseRecruited UPDATE job_position SET recruited recruited 1 WHERE id #{jobId} AND recruited lt; #{headcount} /update参数说明影响行数 rows 是关键信号。rows 为 0 说明 where 条件不满足即名额已满事务要抛异常回滚确保不会出现「申请记录插进去了但人数没加上」的脏数据。被拒绝的申请记录在重复判断里要排除否则学生被拒绝后就永远无法再申请这属于业务逻辑的隐藏缺陷。审核接口的规则相对简单但状态流转要写清楚申请通过后对应的岗位若 recruited 等于 headcount则应把岗位状态自动改为已满审核拒绝后学生在重复申请条件中不再受限制。这两条规则都建议写在同一个事务里避免状态不一致。4. 用 Vue 搭起学生端与部门端路由守卫、申请与工时填报4.1 路由守卫与 axios 拦截器前端用 Vue 3 加 Element Plus 是比较省力的组合。Route 的 meta 里标注 roles守卫里判断当前用户角色是否在允许列表内不在就重定向到对应首页。token 存在 localStorage用户信息里的 role 字段是路由判断的唯一依据。// router/index.js router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next({ path: /login }) return } const role parseInt(localStorage.getItem(role)) if (to.meta.roles !to.meta.roles.includes(role)) { next(role 1 ? /department : /student) return } next() })逻辑说明第一个判断拦截未登录访问第二个判断拦截角色越权。role 存的是数字从 localStorage 取出来是字符串务必 parseInt 转换这个 bug 会让所有角色判断失效属于经典低级错误。axios 封装是前端工程的地基。请求拦截器统一加 Authorization 头响应拦截器统一处理 401 和业务错误码。后端返回结构统一用 { code, message, data }前端就能用一套逻辑消化全部异常。// request.js const service axios.create({ baseURL: /api, timeout: 15000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { localStorage.clear() router.push(/login) } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } )参数说明timeout 设 15 秒防止后端某个接口卡死时前端白屏无反馈。401 时清空本地存储并跳登录对应后端 JWT 过期场景。业务错误码统一在响应拦截器弹提示业务代码里就不用每个接口都写一遍错误分支这是能省下大量重复代码的习惯。4.2 岗位列表与申请按钮的边界条件岗位列表页是学生的入口需要体现三样东西分页搜索、岗位状态映射、申请按钮的禁用逻辑。申请按钮的禁用条件不是单一的要同时看登录状态、岗位状态、人数是否已满、当前用户是否已申请这四种状态组合起来才是完整的边界控制。template el-table :datalist v-loadingloading el-table-column proptitle label岗位名称 / el-table-column label时薪 template #default{ row } {{ row.hourlyWage }} 元/小时 /template /el-table-column el-table-column label名额 template #default{ row } {{ row.recruited }} / {{ row.headcount }} /template /el-table-column el-table-column label状态 template #default{ row } el-tag :typestatusType(row.status){{ statusText(row.status) }}/el-tag /template /el-table-column el-table-column label操作 template #default{ row } el-button typeprimary sizesmall :disabled!canApply(row) clickhandleApply(row) {{ appliedIds.includes(row.id) ? 已申请 : 申请 }} /el-button /template /el-table-column /el-table /templatecanApply 方法建议写成独立函数不要揉在模板里。它要做四层判断岗位状态是招聘中、已招人数小于总人数、当前用户没申请过、当前用户角色是学生。这四层判断同时满足才能点申请。把逻辑抽出来还有一个额外好处后端接口的校验规则和前端完全对齐答辩时可以说「前端控制体验后端保证安全」。申请按钮点击后用返回结果决定是否刷新列表。常见错误是点击后直接给成功提示不管后端返回什么。后端返回「名额已满」时前端仍然提示成功这就属于前后端状态不同步非常掉价。4.3 工时填报与部门确认状态流转的双端协作工时填报是学生端另一个核心功能表单需要日期和时长两个关键输入。日期限制在当月范围内已经确认过的日期不能重复填报时长的步进设为 0.5范围从 0.5 到 8 小时。提交时把 student_id 和 job_id 塞进隐藏字段因为后端要从 token 里取用户身份学生 ID 不能信任前端传值。部门端的确认列表结构是另一个维度按「待确认」工时记录来展示标题用学生的姓名和所属岗位拼接。每条记录两个操作确认和驳回。驳回时可以要求填理由这个理由在答辩演示中很容易被问到建议做进去。确认操作后工时记录状态变为已确认不可再次修改。学生填报工时(待确认) → 部门确认(已确认) → 结算时纳入统计 ↘ 部门驳回 → 学生可查看驳回原因后重新填报这个状态流转图虽然简单却是薪酬结算的数据基础。我在模拟项目X里见过一种做法部门确认时把金额算好存进工时表导致一个月后岗位时薪变化历史工资金额跟着漂移结算完全对不上。正确做法是工时表只存小时数和状态金额在结算时按岗位时薪快照计算不要在确认环节就把钱定死。前端角色控制还有个细节按钮的显示用 v-if 判断当前角色而不是用 disabled 隐藏。学生端根本看不到「确认工时」按钮部门端根本看不到「申请岗位」按钮这样才符合权限隔离的直觉。把 role 判断封装成自定义指令会让模板干净很多答辩时提一句「封装了权限指令」印象分会不一样。5. 勤工俭学系统开发避坑5 个高频踩坑点5.1 现象登录成功后页面不到两分钟就掉线表现是页面操作到一半突然跳回登录页输入账号密码又能进来但过一会儿又掉了。原因几乎都是 JWT 过期时间设置有问题有人把过期时间写成秒数却当作毫秒用有人是刷新页面时把 token 一起清掉了还有人是后端拦截器把每个请求都当成新会话token 根本没存住。解决先确认 jwt.expire-hours 在配置里的值生成 token 的时间单位是小时乘以 3600 再乘以 1000换算成毫秒。前端刷新页面不清 tokenlocalStorage 里的 token 要等 401 时才清除。如果你做了记住登录状态可以加一层 refreshToken 机制但毕设阶段把 accessToken 有效期设成 2 小时足够演示别过度设计。5.2 现象部门审核通过后岗位详情里的「已招人数」纹丝不动表现是审核列表状态正常更新但回到岗位列表招募人数还是审核前的数字。原因大概率是审核接口只更新了申请记录的状态没有调用岗位表的人数增加逻辑。申请通过和名额占要是两件事代码里只做了一件。解决审核通过的业务方法里必须同时执行「更新申请状态为通过」和「recruited 字段加一」。把两步放在同一个事务方法里任何一个失败都整体回滚。推荐在 Service 层写一个 auditPass 方法封装这两个操作并且要复用申请时的原子更新 SQL不能另写一条不带条件的 update。5.3 现象月度工资汇总和 Excel 手工核算结果差几分钱表现是系统里显示总金额是 1000.00手工拿计算器按却是 999.98。原因几乎可以断定是用了 double 或 FLOAT 存金额和工时浮点数在累加时会产生误差。0.1 加 0.2 不等于 0.3后端的 double 求和也会积累这种误差越汇总越明显。解决从数据库到 Java 代码全链路用定点数。表字段 DECIMAL(10,2)实体属性用 BigDecimalJava 求和用 BigDecimal.add不要用 号。工时字段虽然允许一位小数但录入时按 0.5 的倍数约束避免出现 1.1 小时这种无法用二进制精确表示的值。这个坑属于「知道一次就不再犯」的类型答辩时主动讲出来反而是加分项。5.4 现象并发申请最后一个名额系统录进去了 5 个人表现是岗位只招 5 人压测时 10 个请求同时打进来apply_record 表里多了 10 条待审核记录recruited 也涨到了 10。原因就是应用层的 check-then-act 竞态先查人数再插入两条请求同时查到人数为 4都认为自己还有名额然后都执行了插入。这是经典并发问题不是玄学。解决用数据库的原子更新做名额扣减也就是第 3 章里的 increaseRecruited把「判断名额」和「名额加一」合并到一条 UPDATE 语句里。WHERE 条件 recruited headcount 在数据库层面加锁并发请求只有一个能更新成功其余返回影响行数为 0事务回滚。如果不想写自定义 SQL也可以用 SELECT ... FOR UPDATE 做悲观锁但毕设阶段原子更新是更优雅的方案也更好讲。5.5 现象导出 Excel 文件名是乱码打开内容也乱表现是部署到服务器后下载的工资明细文件名显示为 %E5%B7%A5%E8%B5%84%……用 Excel 打开后中文内容变成问号。原因是响应头的 Content-Disposition 里直接拼了中文文件名不同浏览器对非 ASCII 字符的处理方式不同。Tomcat 8 以上版本对 URL 编码的兼容性比直接传中文好。解决文件名用 URLEncoder 编码后拼接进 Content-Disposition并加上 filename* 参数。同时确保 POI 生成的 xlsx 内容本身用了 UTF-8服务端向浏览器输出时指定字符集。代码层面有个小技巧attachment; filename*UTF-8 编码后的文件名这种写法在现代浏览器里全部兼容。这个坑解决后把格式写在单元测试里固定下来防止日后被改回去。6. 答辩前值得做的三件事造数据、写测试、压一把接口第一件事是造数据。空库跑系统的演示效果非常单薄分页只有一页、报表只有一行、图表拉不出曲线。我用一个 SQL 脚本批量生成数据比一条条 insert 高效得多300 个学生、30 个岗位、500 条申请记录、1000 条工时记录、12 个月的结算单。生成时注意两点工时要跨月份分布才能演示结算的月度筛选申请记录的状态要覆盖待审核、通过、拒绝三种审核列表才有内容可看。第二件事是给核心业务写接口测试别怕花时间。覆盖四个主流程登录成功与失败、岗位申请成功与名额已满、审核通过后人数回写、月度结算金额计算。用 MockMvc 模拟请求断言返回码和数据库记录变化。这四类测试跑通答辩时被问到边界情况可以直接说「这块有测试覆盖」评审的追问方向会明显收敛。Test Transactional void applyWhenFull_shouldFail() { // 构造一个 headcount1 且已满员的岗位 JobPosition job new JobPosition(); job.setHeadcount(1); job.setRecruited(1); job.setStatus(0); jobPositionMapper.insert(job); Result result workStudyService.applyJob(2L, job.getId()); assertTrue(result.isSuccess() false); assertEquals(岗位名额已满, result.getMessage()); }第三件事是压一把接口重点压岗位申请。不需要全面性能测试单测一个接口的手工并发即可开 20 个线程同时申请最后一个名额断言申请记录只有一条成功、recruited 不超过 headcount。这一步直接验证第 5 章的防超录方案也让你在答辩演示时心里有底。评审如果问「并发怎么办」现场展示这条测试比任何口头解释都可信。我从这类项目里得到的最大教训是毕设系统的代码量不大但完整性要求很高。把登录、申请、审核、结算、角色控制串成一条干净的闭环再把测试和边界情况的答案准备好这个题目就立住了。至于那些漂亮花哨的动画页面优先级远低于数据一致性和权限安全别把力气用反方向。希望帮到你。本文还有配套的精品资源点击获取
简介毕设学生勤工俭学系统.zip 是一份面向高校毕业设计环节的完整Web应用项目适合计算机相关专业学生用于课程设计或毕业课题参考。项目围绕高校勤工俭学管理场景实现岗位发布、学生申请、工时记录、工资计算与双向评价等核心功能可用于理解校园服务类信息系统的完整开发流程涵盖需求分析、系统设计、编码实现、测试与文档编写等软件开发全过程要素。资源包共638个文件约6.6MB以gif动图、js脚本、html/jsp页面、java/class代码、jar依赖库为主另含css样式、db/mdf数据库文件、doc说明文档及辅助脚本基本覆盖从源码到运行环境的典型文件类型。目前已有1086人学习下载。压缩包同时提供asp、php等多语言文件与完整项目结构便于读者对照JSP实现方式进行比较学习对掌握MVC分层、Servlet处理请求、JDBC数据库交互及前端布局调试均有实际参考价值。1. 为什么毕设圈的勤工俭学系统值得你认真做一遍手上拿到「毕设 学生勤工俭学系统.zip」这个压缩包时很多人第一反应是解压看代码。但我建议你先别急着拆想清楚一个问题这套系统凭什么能当毕设题目。勤工俭学系统本质是典型的管理信息系统学生、用工部门、管理员三种角色串起一条完整业务链岗位发布、在线申请、工时填报、薪酬结算。它不像算法题那样拼模型效果评审更在意流程是否闭环、表设计是否合理、权限边界是否讲得清。选这个题的人大多是想用一套代码把 Web 全链路走通顺便在答辩时把每个表、每个状态机说透。这篇笔记我就按这个目标拆开讲。2. 把需求拆成实体用户、岗位、工时与结算的六张核心表2.1 三种角色与权限边界勤工俭学系统的业务闭环比图书管理多一层「结算」比宿舍管理多一层「审核」。先用角色把权限边界划清楚后面写接口才不会乱。常见做法是分三种角色学生负责浏览岗位、提交申请、填报工时、查看工资单用工部门负责发布岗位、审核申请、确认工时管理员负责用户管理、岗位兜底、月度结算和统计报表。权限边界在代码里怎么落毕设规模不需要引入重型权限框架用用户表的角色字段加前端路由守卫就够了。后端接口按角色校验前端按角色隐藏按钮两层都做才能算完整的权限闭环。我在模拟项目X里见过只做了前端隐藏、后端接口裸奔的翻车案例答辩时被追问一句「直接调接口怎么办」就卡住了。有人会纠结要不要拆成 user、student、department 三张表。我建议合成一张用户表加 role 字段理由有三登录逻辑统一、关联查询少一次 join、答辩讲 RBAC 概念更直观。部门名称等属性作为冗余字段放在用户表里只有管理员能看到角色为「用工部门」的用户记录。2.2 六张核心表的字段设计与关联表数量控制在六张以内既覆盖业务又不显得堆砌。这是我给这个题固定下来的清单字段只列关键项其余按常规补充即可。表名关键字段说明sys_userid, username, password, real_name, role, dept_name, statusrole 用 0/1/2 分别表示学生、部门、管理员job_positionid, title, description, dept_id, hourly_wage, headcount, recruited, status状态分招聘中、已满、已截止apply_recordid, student_id, job_id, status, apply_time状态分待审核、通过、拒绝work_logid, student_id, job_id, work_date, hours, status, confirm_time状态分待确认、已确认、驳回salary_settlementid, student_id, month, total_hours, total_amount, status状态分未发放、已发放announcementid, title, content, create_time公告表用于丰富页面和答辩素材几个字段设计的细节必须提前定好密码字段不能存明文用 BCrypt 加密长度给 60工时按 0.5 小时为最小颗粒度用 DECIMAL(4,1) 而不是 FLOAT免得 0.1 的精度问题让你在结算时抓狂金额统一 DECIMAL(10,2)所有涉及钱的字段都不许用 double。外键我建议只做逻辑关联不加物理外键理由在避坑章里细说。2.3 工时与薪酬的冗余字段结算口径在答辩前就要统一薪酬结算是这个系统的灵魂评审几乎必问工资是怎么算出来的。这里要定一条口径并在答辩时咬死某个结算月内学生所有「已确认」工时的汇总 — 每个岗位的时薪取该月最后一条确认记录的岗位时薪按岗位分别计算后求和。写成公式就是 月工资 Σ(岗位时薪 × 该岗位当月已确认工时)。salary_settlement 表里冗余 total_hours 和 total_amount 两个快照字段不是多此一举。岗位的 hourly_wage 随时可能被部门修改如果不做快照下个月查历史工资单时数值就漂移了这在财务上是不可接受的。同理核算结束并标记「已发放」后前端要把当月的工时填报入口锁掉不然数据越改越乱。这个冗余设计还能引出另一个答辩亮点结算时读取的是快照字段需要追溯明细时再按 month 关联 work_log 和 job_position。所以我在设计表时故意不加外键就是为了让快照能脱离岗位表独立存活。你把这个理由讲出来比单纯说「我建了外键保证一致性」要有说服力得多。3. 用 Spring Boot 把登录和岗位申请跑通JWT 与状态机3.1 工程结构与配置文件后端我选 Spring Boot 加 MyBatis-Plus原因很简单MyBatis-Plus 的单表 CRUD 不用写 SQL能把精力省给状态机和事务这些真正的核心逻辑。Spring Security 这个阶段没必要上一个拦截器加一个 JWT 工具类就能把权限说清楚答辩时也更容易对着代码讲。工程结构按职责分层别把所有类堆在一个包下。我一般会分成 controller、service、mapper、entity、common 五个包common 下放统一返回结果、JwtUtil、异常处理和拦截器。pom 里最关键的依赖就四个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependencyjjwt 0.9.1 是毕设圈最常见的版本网上资料多遇到问题好搜。MyBatis-Plus 版本别追新3.5.x 足够稳定。配置文件里除了数据源要把 JWT 的几个参数外置方便答辩时现场调过期时间。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/workstudy?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: 一串长度超过32位的随机字符串 expire-hours: 2 upload: path: /data/workstudy/files参数说明数据库连接串必须带 characterEncodingutf8 和 serverTimezone这两个不加中文乱码和时区报错会各坑你一次。jwt.secret 至少 32 位太短会报签名异常。upload.path 我直接指向项目外部目录理由在避坑章第 4 条展开。3.2 JWT 登录与拦截器三个类的核心代码登录接口走「校验用户名密码 → 生成 token → 返回用户信息」三步。密码校验用 BCrypt数据库里存的必须是加密后的密文绝不能明文。JwtUtil 是核心生成 token 时把 userId 和 role 塞进 claim后续接口全靠这两个字段做身份识别。Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire-hours}) private int expireHours; public String generateToken(Long userId, Integer role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expireHours * 3600 * 1000L)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody(); } }逻辑说明setSubject 存用户 IDclaim 里带角色这样拦截器解析一次 token 就能同时拿到身份和权限不用再查一次数据库。过期时间单位换算成毫秒别漏了 *1000L否则两个小时就变成两秒钟这是最常见的翻车点。登录 Controller 写出来很短但有个细节值得注意返回前把密码字段置空前端拿到用户信息里不该有密码密文这是安全习惯也是评审可能挑刺的点。RestController RequestMapping(/api/auth) public class AuthController { Autowired private UserService userService; Autowired private JwtUtil jwtUtil; PostMapping(/login) public Result login(RequestBody LoginDTO dto) { User user userService.findByUsername(dto.getUsername()); if (user null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } if (user.getStatus() 0) { return Result.error(账号已被禁用); } String token jwtUtil.generateToken(user.getId(), user.getRole()); user.setPassword(null); return Result.success(new LoginVO(token, user)); } }逻辑说明先查用户再验证密码两个条件合并判断避免用户名不存在和密码错误两种提示不一致导致信息泄露。status 字段做启用禁用这个字段在答辩演示禁用账号时很出效果。拦截器的核心是解析 token 并塞进 request 上下文后续接口从 request attribute 里取 userId 和 role。注意排除登录接口否则会出现「登录接口也要先登录」的死循环。Component public class JwtInterceptor implements HandlerInterceptor { Autowired private JwtUtil jwtUtil; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getMethod().equals(OPTIONS)) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { writeUnauthorized(response); return false; } try { Claims claims jwtUtil.parseToken(token.substring(7)); request.setAttribute(userId, Long.parseLong(claims.getSubject())); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { writeUnauthorized(response); return false; } } }拦截器里先处理 OPTIONS 预检请求这是前后端分离部署时最容易忘的一步。解析失败统一返回 401前端 axios 拦截到 401 就跳转登录页。注册拦截器时注意路径匹配/api/auth/login 和 /api/auth/register 这类匿名接口必须排除。3.3 岗位申请与审核状态机的接口设计岗位申请是并发压力最集中的地方也是答辩时最容易暴露问题的环节。业务规则有三条岗位状态必须是招聘中、已录用人数不能超过总人数、同一学生不能重复申请同一岗位。三条规则看着简单并发一上来就出事原因后面专门写。申请接口的事务逻辑要这样写先查岗位状态和人数再查重复申请记录校验通过后插入申请记录最后执行一条原子更新的 SQL 去累计已招人数。Transactional public Result applyJob(Long studentId, Long jobId) { JobPosition job jobPositionMapper.selectById(jobId); if (job null || job.getStatus() ! 0) { return Result.error(岗位不存在或已停止招聘); } Long count applyRecordMapper.selectCount( new LambdaQueryWrapperApplyRecord() .eq(ApplyRecord::getStudentId, studentId) .eq(ApplyRecord::getJobId, jobId) .ne(ApplyRecord::getStatus, 2)); if (count 0) { return Result.error(您已申请过该岗位); } int rows jobPositionMapper.increaseRecruited(jobId, job.getHeadcount()); if (rows 0) { return Result.error(岗位名额已满); } ApplyRecord record new ApplyRecord(); record.setStudentId(studentId); record.setJobId(jobId); record.setStatus(0); applyRecordMapper.insert(record); return Result.success(申请成功等待部门审核); }关键在 increaseRecruited 这条自定义 SQL它把「检查人数」和「增加人数」合并成一条原子操作。触发的条件用 recruited headcount 写在 where 子句里靠数据库行锁挡住并发而不是靠应用层的 if 判断。update idincreaseRecruited UPDATE job_position SET recruited recruited 1 WHERE id #{jobId} AND recruited lt; #{headcount} /update参数说明影响行数 rows 是关键信号。rows 为 0 说明 where 条件不满足即名额已满事务要抛异常回滚确保不会出现「申请记录插进去了但人数没加上」的脏数据。被拒绝的申请记录在重复判断里要排除否则学生被拒绝后就永远无法再申请这属于业务逻辑的隐藏缺陷。审核接口的规则相对简单但状态流转要写清楚申请通过后对应的岗位若 recruited 等于 headcount则应把岗位状态自动改为已满审核拒绝后学生在重复申请条件中不再受限制。这两条规则都建议写在同一个事务里避免状态不一致。4. 用 Vue 搭起学生端与部门端路由守卫、申请与工时填报4.1 路由守卫与 axios 拦截器前端用 Vue 3 加 Element Plus 是比较省力的组合。Route 的 meta 里标注 roles守卫里判断当前用户角色是否在允许列表内不在就重定向到对应首页。token 存在 localStorage用户信息里的 role 字段是路由判断的唯一依据。// router/index.js router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next({ path: /login }) return } const role parseInt(localStorage.getItem(role)) if (to.meta.roles !to.meta.roles.includes(role)) { next(role 1 ? /department : /student) return } next() })逻辑说明第一个判断拦截未登录访问第二个判断拦截角色越权。role 存的是数字从 localStorage 取出来是字符串务必 parseInt 转换这个 bug 会让所有角色判断失效属于经典低级错误。axios 封装是前端工程的地基。请求拦截器统一加 Authorization 头响应拦截器统一处理 401 和业务错误码。后端返回结构统一用 { code, message, data }前端就能用一套逻辑消化全部异常。// request.js const service axios.create({ baseURL: /api, timeout: 15000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { localStorage.clear() router.push(/login) } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } )参数说明timeout 设 15 秒防止后端某个接口卡死时前端白屏无反馈。401 时清空本地存储并跳登录对应后端 JWT 过期场景。业务错误码统一在响应拦截器弹提示业务代码里就不用每个接口都写一遍错误分支这是能省下大量重复代码的习惯。4.2 岗位列表与申请按钮的边界条件岗位列表页是学生的入口需要体现三样东西分页搜索、岗位状态映射、申请按钮的禁用逻辑。申请按钮的禁用条件不是单一的要同时看登录状态、岗位状态、人数是否已满、当前用户是否已申请这四种状态组合起来才是完整的边界控制。template el-table :datalist v-loadingloading el-table-column proptitle label岗位名称 / el-table-column label时薪 template #default{ row } {{ row.hourlyWage }} 元/小时 /template /el-table-column el-table-column label名额 template #default{ row } {{ row.recruited }} / {{ row.headcount }} /template /el-table-column el-table-column label状态 template #default{ row } el-tag :typestatusType(row.status){{ statusText(row.status) }}/el-tag /template /el-table-column el-table-column label操作 template #default{ row } el-button typeprimary sizesmall :disabled!canApply(row) clickhandleApply(row) {{ appliedIds.includes(row.id) ? 已申请 : 申请 }} /el-button /template /el-table-column /el-table /templatecanApply 方法建议写成独立函数不要揉在模板里。它要做四层判断岗位状态是招聘中、已招人数小于总人数、当前用户没申请过、当前用户角色是学生。这四层判断同时满足才能点申请。把逻辑抽出来还有一个额外好处后端接口的校验规则和前端完全对齐答辩时可以说「前端控制体验后端保证安全」。申请按钮点击后用返回结果决定是否刷新列表。常见错误是点击后直接给成功提示不管后端返回什么。后端返回「名额已满」时前端仍然提示成功这就属于前后端状态不同步非常掉价。4.3 工时填报与部门确认状态流转的双端协作工时填报是学生端另一个核心功能表单需要日期和时长两个关键输入。日期限制在当月范围内已经确认过的日期不能重复填报时长的步进设为 0.5范围从 0.5 到 8 小时。提交时把 student_id 和 job_id 塞进隐藏字段因为后端要从 token 里取用户身份学生 ID 不能信任前端传值。部门端的确认列表结构是另一个维度按「待确认」工时记录来展示标题用学生的姓名和所属岗位拼接。每条记录两个操作确认和驳回。驳回时可以要求填理由这个理由在答辩演示中很容易被问到建议做进去。确认操作后工时记录状态变为已确认不可再次修改。学生填报工时(待确认) → 部门确认(已确认) → 结算时纳入统计 ↘ 部门驳回 → 学生可查看驳回原因后重新填报这个状态流转图虽然简单却是薪酬结算的数据基础。我在模拟项目X里见过一种做法部门确认时把金额算好存进工时表导致一个月后岗位时薪变化历史工资金额跟着漂移结算完全对不上。正确做法是工时表只存小时数和状态金额在结算时按岗位时薪快照计算不要在确认环节就把钱定死。前端角色控制还有个细节按钮的显示用 v-if 判断当前角色而不是用 disabled 隐藏。学生端根本看不到「确认工时」按钮部门端根本看不到「申请岗位」按钮这样才符合权限隔离的直觉。把 role 判断封装成自定义指令会让模板干净很多答辩时提一句「封装了权限指令」印象分会不一样。5. 勤工俭学系统开发避坑5 个高频踩坑点5.1 现象登录成功后页面不到两分钟就掉线表现是页面操作到一半突然跳回登录页输入账号密码又能进来但过一会儿又掉了。原因几乎都是 JWT 过期时间设置有问题有人把过期时间写成秒数却当作毫秒用有人是刷新页面时把 token 一起清掉了还有人是后端拦截器把每个请求都当成新会话token 根本没存住。解决先确认 jwt.expire-hours 在配置里的值生成 token 的时间单位是小时乘以 3600 再乘以 1000换算成毫秒。前端刷新页面不清 tokenlocalStorage 里的 token 要等 401 时才清除。如果你做了记住登录状态可以加一层 refreshToken 机制但毕设阶段把 accessToken 有效期设成 2 小时足够演示别过度设计。5.2 现象部门审核通过后岗位详情里的「已招人数」纹丝不动表现是审核列表状态正常更新但回到岗位列表招募人数还是审核前的数字。原因大概率是审核接口只更新了申请记录的状态没有调用岗位表的人数增加逻辑。申请通过和名额占要是两件事代码里只做了一件。解决审核通过的业务方法里必须同时执行「更新申请状态为通过」和「recruited 字段加一」。把两步放在同一个事务方法里任何一个失败都整体回滚。推荐在 Service 层写一个 auditPass 方法封装这两个操作并且要复用申请时的原子更新 SQL不能另写一条不带条件的 update。5.3 现象月度工资汇总和 Excel 手工核算结果差几分钱表现是系统里显示总金额是 1000.00手工拿计算器按却是 999.98。原因几乎可以断定是用了 double 或 FLOAT 存金额和工时浮点数在累加时会产生误差。0.1 加 0.2 不等于 0.3后端的 double 求和也会积累这种误差越汇总越明显。解决从数据库到 Java 代码全链路用定点数。表字段 DECIMAL(10,2)实体属性用 BigDecimalJava 求和用 BigDecimal.add不要用 号。工时字段虽然允许一位小数但录入时按 0.5 的倍数约束避免出现 1.1 小时这种无法用二进制精确表示的值。这个坑属于「知道一次就不再犯」的类型答辩时主动讲出来反而是加分项。5.4 现象并发申请最后一个名额系统录进去了 5 个人表现是岗位只招 5 人压测时 10 个请求同时打进来apply_record 表里多了 10 条待审核记录recruited 也涨到了 10。原因就是应用层的 check-then-act 竞态先查人数再插入两条请求同时查到人数为 4都认为自己还有名额然后都执行了插入。这是经典并发问题不是玄学。解决用数据库的原子更新做名额扣减也就是第 3 章里的 increaseRecruited把「判断名额」和「名额加一」合并到一条 UPDATE 语句里。WHERE 条件 recruited headcount 在数据库层面加锁并发请求只有一个能更新成功其余返回影响行数为 0事务回滚。如果不想写自定义 SQL也可以用 SELECT ... FOR UPDATE 做悲观锁但毕设阶段原子更新是更优雅的方案也更好讲。5.5 现象导出 Excel 文件名是乱码打开内容也乱表现是部署到服务器后下载的工资明细文件名显示为 %E5%B7%A5%E8%B5%84%……用 Excel 打开后中文内容变成问号。原因是响应头的 Content-Disposition 里直接拼了中文文件名不同浏览器对非 ASCII 字符的处理方式不同。Tomcat 8 以上版本对 URL 编码的兼容性比直接传中文好。解决文件名用 URLEncoder 编码后拼接进 Content-Disposition并加上 filename* 参数。同时确保 POI 生成的 xlsx 内容本身用了 UTF-8服务端向浏览器输出时指定字符集。代码层面有个小技巧attachment; filename*UTF-8 编码后的文件名这种写法在现代浏览器里全部兼容。这个坑解决后把格式写在单元测试里固定下来防止日后被改回去。6. 答辩前值得做的三件事造数据、写测试、压一把接口第一件事是造数据。空库跑系统的演示效果非常单薄分页只有一页、报表只有一行、图表拉不出曲线。我用一个 SQL 脚本批量生成数据比一条条 insert 高效得多300 个学生、30 个岗位、500 条申请记录、1000 条工时记录、12 个月的结算单。生成时注意两点工时要跨月份分布才能演示结算的月度筛选申请记录的状态要覆盖待审核、通过、拒绝三种审核列表才有内容可看。第二件事是给核心业务写接口测试别怕花时间。覆盖四个主流程登录成功与失败、岗位申请成功与名额已满、审核通过后人数回写、月度结算金额计算。用 MockMvc 模拟请求断言返回码和数据库记录变化。这四类测试跑通答辩时被问到边界情况可以直接说「这块有测试覆盖」评审的追问方向会明显收敛。Test Transactional void applyWhenFull_shouldFail() { // 构造一个 headcount1 且已满员的岗位 JobPosition job new JobPosition(); job.setHeadcount(1); job.setRecruited(1); job.setStatus(0); jobPositionMapper.insert(job); Result result workStudyService.applyJob(2L, job.getId()); assertTrue(result.isSuccess() false); assertEquals(岗位名额已满, result.getMessage()); }第三件事是压一把接口重点压岗位申请。不需要全面性能测试单测一个接口的手工并发即可开 20 个线程同时申请最后一个名额断言申请记录只有一条成功、recruited 不超过 headcount。这一步直接验证第 5 章的防超录方案也让你在答辩演示时心里有底。评审如果问「并发怎么办」现场展示这条测试比任何口头解释都可信。我从这类项目里得到的最大教训是毕设系统的代码量不大但完整性要求很高。把登录、申请、审核、结算、角色控制串成一条干净的闭环再把测试和边界情况的答案准备好这个题目就立住了。至于那些漂亮花哨的动画页面优先级远低于数据一致性和权限安全别把力气用反方向。希望帮到你。本文还有配套的精品资源点击获取
