简介这是一份面向高校计算机相关专业毕业设计的完整论文文档主题为校园勤工俭学兼职系统。系统基于B/S架构采用Java、Spring Boot框架搭配Eclipse、Maven、Mariadb 10.5和Tomcat 8.5等主流工具前端使用HTML5与CSS3论文中详细阐述了项目背景、技术选型、系统设计与实现过程适合正在准备毕设或希望了解前后端分离开发流程的读者参考。资源包仅包含1个docx文件大小约6.17MB文件结构完整除了中英文摘要、目录、绪论外还覆盖了需求分析、数据库设计、功能模块划分等毕业设计关键章节。该论文结构清晰、内容翔实有助于快速理解校园兼职系统从需求到落地的完整流程并为同类管理系统的设计与论文写作提供有价值的借鉴。已有158人学习过。 毕设题目前面加上“javavuespringboot”三个词看着像任务书里拼出来的但真把这套技术栈做完还写成论文的多少都得脱层皮。我去年拿的就是这个题目从需求分析、数据库设计、后端接口、前端页面到最后定稿查重和答辩前后扎扎实实折腾了将近三个月。这篇文章把我踩过的坑和总结出来的做法一次性说清楚包括选型逻辑、核心模块怎么落地、论文章节怎么安排、答辩时容易被问什么以及一些调试到半夜才发现的鬼问题。准备做同类系统的同学或者想用 Spring Boot Vue 练一个完整全栈项目的朋友这篇应该能帮你们少走不少弯路。1. 项目背景与整体设计思路1.1 勤工俭学业务的真实痛点校园勤工俭学这件事看起来就是“发岗位、学生报名、老师审核、月底算钱”但真正走一遍线下流程就知道有多乱。我前期调研了学校资助中心的实际工作方式发现他们主要靠微信群发 Excel 表格收集报名学生提交申请表后再人工汇总岗位信息散落在各条聊天记录里学生根本不知道哪些岗位还没招满。用工部门想发布需求要先找老师要模板月底统计工时更是灾难纸质单据经常对不上。所以这个系统的核心价值不是“有个网站能登录”而是把一条完整业务链搬到线上管理员发布勤工俭学岗位、学生浏览和申请、用工单位或管理员审核、录用后登记考勤工时、月末按工时结算补贴、学生随时查自己的工资记录。除了学生和管理员这两个最明显的角色系统还要考虑“用工部门”的诉求。食堂、图书馆、行政办公室这些部门人员情况不一样有的希望自己审核简历有的希望直接由资助中心统一分配权限设计上就得留出灵活度。1.2 为什么是 Java Vue Spring Boot选这套技术栈不是因为它时髦而是因为它资料多、生态成熟、出问题搜得到答案。Java 作为后端主力语言学校课程里教过 JavaWeb 和 SSMSpring Boot 又把这些繁琐的配置大幅简化做一个小型管理系统完全够用。Vue 在前端领域的学习曲线相对平缓组件化和响应式数据让页面开发效率很高而且前后端分离的架构在毕业论文里能写出东西——至少“团队协作、独立部署、接口解耦”这些点都能展开讲。我见过不少同学在这个环节纠结要不要上微服务、要不要加 Redis 缓存、要不要搞工作流引擎。实话实说如果一个毕设项目团队只有你一个人题目还是“校园勤工俭学系统”尽量不要为了炫技给自己挖坑。技术栈选定 Java Spring Boot Vue MySQL MyBatis-Plus在论文里清楚交代每个组件解决什么问题就够了。等系统跑通如果还想做亮点再讨论式地提一嘴“后续可引入工作流引擎提升审批灵活性”比从第一天就背一个大包袱要舒服得多。2. 系统架构与工程搭建2.1 前后端分离架构与工程结构我这个项目采用的是前后端分离结构前端是一个独立的 Vue 工程后端是一个 Spring Boot 工程之间通过 JSON 格式的 RESTful 接口通信。后端默认跑在 8080 端口前端开发环境通过 Vite 配置代理解决跨域问题。生产环境则把前端打包后的 dist 目录交给 Nginx 托管接口地址统一走/api前缀。后端工程包名我建议按职责分层不要一股脑塞进 controller 包里。举个例子com.campus.job ├── controller # 接收请求做参数校验 ├── service # 业务逻辑 ├── mapper # MyBatis-Plus 数据访问层 ├── entity # 数据库实体 ├── dto # 前端传输对象 ├── vo # 返回视图对象 ├── config # 配置类比如拦截器、跨域 └── common # 统一返回结果、异常处理、工具类这样分层最大的好处是写论文时可以直接对应章节第三章讲“控制层设计”第四章讲“业务层核心逻辑实现”每一层都有代码片段可贴。很多同学最后卡在“论文没东西可写”本质上是代码结构太乱连自己都讲不清楚模块边界。包结构清晰之后画架构图、时序图、类图也顺手很多。构建工具我用的 Maven版本管理用 Git本地代码推到 Gitee 私有仓库。建议大家在开发第一天就把 Git 用起来不是等代码写了一半再初始化。我那时候每完成一个模块就提交一次回滚版本非常方便写论文截图的时候还能找回早期接口设计的改动记录。2.2 数据库设计与核心表结构勤工俭学系统数据库怎么设计直接决定后面开发流程顺不顺。我第一版表建了十几张后来发现很多字段冗余逻辑混乱花了整整一晚上重构。最终稳定下来的核心表大概是这些表名核心作用关键字段user用户表三种角色用 role 字段区分username, password, role, real_name, phoneposition勤工俭学岗位表title, description, department_id, headcount, status, salary_hourapplication学生申请记录student_id, position_id, status, apply_time, remarkattendance工时签到/考勤记录student_id, position_id, work_date, hours, confirm_statussalary月工资结算表student_id, month, total_hours, total_amount, statusdepartment用工部门表name, contact_person, contact_phone角色字段我直接用role字符串区分student、employer、admin没有单独建权限表。因为系统最多 3 种角色权限控制通过后端拦截器按角色校验就能解决。如果角色数量真的多到要动态配置再考虑 RBAC 表但毕设场景真没必要。这里要专门提一个容易踩的坑password 字段一定要存加密后的结果不要用明文。我用的 BCrypt 加密Spring Security 自带的BCryptPasswordEncoder可以直接用。另外一个坑是时间字段工资结算按“月”统计我建议在salary表里直接用month字段存类似2025-06的字符串清晰又方便分组查询别非用datetime加上一堆日期函数去处理。3. 后端核心功能实现细节3.1 登录鉴权与三端角色控制登录是第一个要写的接口也是很多同学代码混乱的重灾区。我采用的方案是 JWT 自定义拦截器没有引入完整的 Spring Security因为学习成本和配置成本加起来对毕设来说偏重。用户登录成功后后端生成一个 token 返回给前端前端每次请求都把它放在请求头Authorization里。后端写一个拦截器统一解析 token并把当前登录用户信息放到ThreadLocal里这样后续业务代码想取用户 ID 就很方便。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { throw new BusinessException(401, 未登录); } // 解析 token获取用户信息并存入 UserContext LoginUser user JwtUtil.parseToken(token); UserContext.set(user); return true; } }角色的接口权限控制我在方法上自定义了一个RequireRole(admin)注解拦截器里判断当前用户角色是否匹配不匹配直接返回“无权限”。这种做法的好处是代码写起来直观论文里也好解释——登录认证管“你是谁”角色校验管“你能做什么”。有个细节值得留意要预留一个“游客也能浏览岗位”的接口。很多同学一上来就把所有接口都锁住了结果学生想看看岗位列表还得先注册登录非常反人类。我在设计接口时岗位列表接口允许匿名访问但申请、审核、考勤这些操作必须登录。3.2 岗位发布与申请流程的稳定性设计岗位发布后学生提交申请这里最容易出现的问题是“超招”——岗位只剩 1 个名额30 个学生同时提交申请结果录取了十几个人。我在第一版代码里也犯了这个错误申请接口逻辑是先查剩余名额大于 0 就插入申请记录。在高并发场景下两个请求同时查到剩余名额等于 1都会插入记录数据一致性就出问题了。解决办法有两种。简单方案是 MySQL 的行锁在position表更新时用UPDATE position SET remaining remaining - 1 WHERE id ? AND remaining 0如果影响行数为 0说明名额已满直接返回“岗位已满”。另一个方案是给application表加唯一约束比如(student_id, position_id)联合唯一从数据库层面防止一个学生对同一岗位重复申请。两种方案最好都做双保险。这个细节写进论文“系统优化与并发控制”里绝对是个加分项。申请被审核通过后学生的状态变为“已录用”此时可以关联attendance表开始记录工时。这里我踩过一个小坑有些岗位的负责人有权直接录用学生有些岗位必须管理员统一分配。我的做法是在position表加了一个hire_mode字段self表示用工部门自行录用admin表示管理员分配。后端判断这个字段再决定是否允许用工部门操作审核接口避免权限越界。3.3 工时登记与工资结算逻辑工时这块我刚开始想得太复杂又是排班表又是签到二维码后来发现以毕设的规模考勤记录把“学生填报、用工单位确认”这个闭环做好就够了。学生登录后可以对已录用的岗位提交每天的工作时间段和工作时长用工单位负责人看到待确认记录核对后点击确认。只有“已确认”状态的工时才会进入工资计算的待选数据。工资结算是一个定时任务也可以用管理员手动触发。如果只是毕设没必要上 xxl-job 这种分布式任务调度框架直接在系统启动时跑一个Scheduled(cron 0 0 2 1 * ?)每月 1 号凌晨两点定时扫描上个月的已确认工时汇总后写入salary表。计算公式很简单总工资 总工时 × 岗位对应的小时单价。需要注意的是一天最多 8 小时普通人不会被允许写代码时要对hours字段做上限校验。这个定时任务在论文里是个很自然的“系统亮点”可以配合图表展示工资流程。我在答辩时被问到“如果月初任务执行失败怎么办”准备的是两个答案一是任务执行前查询当月工资是否已生成避免重复二是失败后管理员可以在页面上手工触发“重新结算”相当于一个兜底策略。这样回答老师基本会点头。4. Vue 前端开发与联调实践4.1 前端工程结构与路由设计前端我使用的是 Vue 3 加 Vite状态管理用 Pinia。写页面之前先规划路由。因为系统有三种角色页面之间的跳转和访问权限要提前想清楚。我的路由设计大概是/login为登录页/student/dashboard为学生工作台/employer/jobs为用工部门岗位管理/admin/users为用户管理。每个人主页是不同路径不完全依靠菜单隐藏来限制页面访问。另外用了 Vue Router 的全局前置守卫在跳转前读取本地存储的 token 和角色信息router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() } else if (!token) { next(/login) } else { next() } })路由守卫可以保证没登录的人进不去页面但这只是前端体验层面的限制真正的安全校验还是在后端做。写论文的时候必须把这个思路讲清楚前端路由控制是为了用户友好后端接口鉴权才是安全底线。有些同学只做了前端拦截后端接口裸奔答辩时被追问“一个懂技术的学生直接发请求怎么办”就答不上来了。Vue 版本方面我用的选项式 API后来也接触了组合式 API。如果是刚入门选项式更直观data、methods、computed丢进去就能跑。组合式 API 更适合逻辑复用要求高的项目。这个选择在论文里也可以稍微提一句体现你了解 Vue 3 两种写法的区别和取舍。4.2 请求封装、拦截器与接口联调前端和后端联调阶段最容易出问题的不是接口逻辑本身而是请求封装的统一性。我把 axios 封装成一个全局实例设置了baseURL为/api然后加请求拦截器自动在 header 中带上 token加响应拦截器统一处理后端返回的数据格式。service.interceptors.response.use( (response) { const res response.data if (res.code 200) { return res.data } if (res.code 401) { router.push(/login) return Promise.reject(new Error(登录过期)) } ElMessage.error(res.msg) return Promise.reject(new Error(res.msg)) }, (error) { ElMessage.error(网络异常) return Promise.reject(error) } )有一类问题非常常见后端返回的数据字段是下划线命名如student_id前端 JS 却习惯用驼峰studentId。如果不想前端到处转字段可以在后端统一加 Jackson 配置把下划线转驼峰。但我的习惯是前端主动适配后端字段规范的接口文档比任何转换配置都可靠。推荐大家用 Apifox 管理接口定义好每个接口的地址、参数、返回示例前端照着文档开发效率能翻倍。联调遇到跨域问题也算家常便饭。开发环境我用 Vite proxy 代理解决生产环境用 Nginx 反向代理把相同域名的/api请求转发到后端服务端口。只要不出现“后端响应了但前端访问不到”的怪问题跨域就基本不会拖太久。5. 毕业论文写作、答辩与常见问题5.1 论文结构安排与图表呈现毕设论文和开发文档完全是两回事它要求的是一条清晰的“提出问题—分析问题—解决问题—验证方案”主线。我的论文大纲可以给大家参考第一章绪论写背景和研究意义、国内外现状第二章相关技术介绍每项技术写清楚版本号和它在这个项目中解决的特定问题第三章系统分析包含可行性分析、功能需求分析、用例图、非功能需求第四章系统设计包含整体架构图、功能模块设计、数据库 ER 图、核心表结构第五章系统实现按角色或模块贴关键代码截图并解释设计意图第六章系统测试写功能测试用例设计和测试结果最后是总结与展望。图表比文字重要得多。实体关系图、系统架构图、用例图、时序图、状态图哪怕画得不复杂也要保证逻辑正确。最忌讳的是论文里用了网上扒下来的课程设计架构图又跟自己系统完全对不上。画图工具用 ProcessOn 或者 draw.io 都行。截代码图时不要整页贴贴关键方法的核心逻辑配 3 到 5 句解释比堆一大篇代码更有说服力。答辩时大概率被问的问题系统有哪些角色、权限是怎么控制的、数据库表之间什么关系、并发申请怎么处理、如何处理数据安全性、前后端如何通信。这些只要你真的是自己一步步调出来的基本都能接住。怕的是只把别人代码跑起来数据字典都说不清一追问就露馅。5.2 高频问题排查与避坑清单开发中我记录了不少代表性的报错在这里列一个速查表方便大家直接对照排错现象常见原因处理方法前端请求 404后端接口路径 RequestMapping 写错或前端 baseURL 不对先看浏览器 Network 里实际请求的 URL和后端控制台日志对照插入数据库中文乱码数据库连接未指定 UTF-8 编码或库表排序规则不对确保 JDBC URL 加characterEncodingutf8建库用 utf8mb4登录后请求 401token 过期或拦截器没有放行预检 OPTIONS 请求拦截器里先放行 OPTIONS再检查 token 解析逻辑前端报跨域本地开发端口和接口端口不一致用 Vite proxy 或在后端加 CORS 配置类上传图片后访问不了静态资源路径映射没配置WebMvcConfigurer 里 addResourceHandlers 指向本地目录有些同学会遇到一个特别恼火的问题项目在自己电脑上跑得好好的换一台电脑就废了。多半是环境变量问题。这里多说一句Java 环境配置时JAVA_HOME 要指向 JDK 安装目录PATH 里加%JAVA_HOME%\bin不要直接写死某个磁盘路径。以后换电脑重装环境会省很多事。还有一个我在测试阶段发现的隐藏 bug学生退出登录以后再换个账号登录页面居然还显示了上一个账号的申请记录。原因是前端用了 Pinia 存储状态退出登录时只清了 token没有清用户信息。后来我统一封装了一个logout()方法token 和用户信息一并清除并跳转登录页。这种“小但影响体验”的问题特别值得写进论文测试章节作为功能测试发现并解决的典型案例。最后再分享一点个人体会做这种管理系统真正费时间的不是写代码而是需求和数据设计。前期跟学校勤工助学相关老师聊清楚流程把表结构设计对了后面写代码就是往框架里填东西的事情。我后来为了论文里能画几张像样的时序图又把核心流程用代码重新走了一遍发现“自己写的东西自己讲清楚”这件事反而比写代码本身更能提升对系统的理解。希望你们做这个题目时也能有同样的收获。本文还有配套的精品资源点击获取 Spring Boot + Vue 全栈开发勤工俭学系统：毕设避坑指南
简介这是一份面向高校计算机相关专业毕业设计的完整论文文档主题为校园勤工俭学兼职系统。系统基于B/S架构采用Java、Spring Boot框架搭配Eclipse、Maven、Mariadb 10.5和Tomcat 8.5等主流工具前端使用HTML5与CSS3论文中详细阐述了项目背景、技术选型、系统设计与实现过程适合正在准备毕设或希望了解前后端分离开发流程的读者参考。资源包仅包含1个docx文件大小约6.17MB文件结构完整除了中英文摘要、目录、绪论外还覆盖了需求分析、数据库设计、功能模块划分等毕业设计关键章节。该论文结构清晰、内容翔实有助于快速理解校园兼职系统从需求到落地的完整流程并为同类管理系统的设计与论文写作提供有价值的借鉴。已有158人学习过。 毕设题目前面加上“javavuespringboot”三个词看着像任务书里拼出来的但真把这套技术栈做完还写成论文的多少都得脱层皮。我去年拿的就是这个题目从需求分析、数据库设计、后端接口、前端页面到最后定稿查重和答辩前后扎扎实实折腾了将近三个月。这篇文章把我踩过的坑和总结出来的做法一次性说清楚包括选型逻辑、核心模块怎么落地、论文章节怎么安排、答辩时容易被问什么以及一些调试到半夜才发现的鬼问题。准备做同类系统的同学或者想用 Spring Boot Vue 练一个完整全栈项目的朋友这篇应该能帮你们少走不少弯路。1. 项目背景与整体设计思路1.1 勤工俭学业务的真实痛点校园勤工俭学这件事看起来就是“发岗位、学生报名、老师审核、月底算钱”但真正走一遍线下流程就知道有多乱。我前期调研了学校资助中心的实际工作方式发现他们主要靠微信群发 Excel 表格收集报名学生提交申请表后再人工汇总岗位信息散落在各条聊天记录里学生根本不知道哪些岗位还没招满。用工部门想发布需求要先找老师要模板月底统计工时更是灾难纸质单据经常对不上。所以这个系统的核心价值不是“有个网站能登录”而是把一条完整业务链搬到线上管理员发布勤工俭学岗位、学生浏览和申请、用工单位或管理员审核、录用后登记考勤工时、月末按工时结算补贴、学生随时查自己的工资记录。除了学生和管理员这两个最明显的角色系统还要考虑“用工部门”的诉求。食堂、图书馆、行政办公室这些部门人员情况不一样有的希望自己审核简历有的希望直接由资助中心统一分配权限设计上就得留出灵活度。1.2 为什么是 Java Vue Spring Boot选这套技术栈不是因为它时髦而是因为它资料多、生态成熟、出问题搜得到答案。Java 作为后端主力语言学校课程里教过 JavaWeb 和 SSMSpring Boot 又把这些繁琐的配置大幅简化做一个小型管理系统完全够用。Vue 在前端领域的学习曲线相对平缓组件化和响应式数据让页面开发效率很高而且前后端分离的架构在毕业论文里能写出东西——至少“团队协作、独立部署、接口解耦”这些点都能展开讲。我见过不少同学在这个环节纠结要不要上微服务、要不要加 Redis 缓存、要不要搞工作流引擎。实话实说如果一个毕设项目团队只有你一个人题目还是“校园勤工俭学系统”尽量不要为了炫技给自己挖坑。技术栈选定 Java Spring Boot Vue MySQL MyBatis-Plus在论文里清楚交代每个组件解决什么问题就够了。等系统跑通如果还想做亮点再讨论式地提一嘴“后续可引入工作流引擎提升审批灵活性”比从第一天就背一个大包袱要舒服得多。2. 系统架构与工程搭建2.1 前后端分离架构与工程结构我这个项目采用的是前后端分离结构前端是一个独立的 Vue 工程后端是一个 Spring Boot 工程之间通过 JSON 格式的 RESTful 接口通信。后端默认跑在 8080 端口前端开发环境通过 Vite 配置代理解决跨域问题。生产环境则把前端打包后的 dist 目录交给 Nginx 托管接口地址统一走/api前缀。后端工程包名我建议按职责分层不要一股脑塞进 controller 包里。举个例子com.campus.job ├── controller # 接收请求做参数校验 ├── service # 业务逻辑 ├── mapper # MyBatis-Plus 数据访问层 ├── entity # 数据库实体 ├── dto # 前端传输对象 ├── vo # 返回视图对象 ├── config # 配置类比如拦截器、跨域 └── common # 统一返回结果、异常处理、工具类这样分层最大的好处是写论文时可以直接对应章节第三章讲“控制层设计”第四章讲“业务层核心逻辑实现”每一层都有代码片段可贴。很多同学最后卡在“论文没东西可写”本质上是代码结构太乱连自己都讲不清楚模块边界。包结构清晰之后画架构图、时序图、类图也顺手很多。构建工具我用的 Maven版本管理用 Git本地代码推到 Gitee 私有仓库。建议大家在开发第一天就把 Git 用起来不是等代码写了一半再初始化。我那时候每完成一个模块就提交一次回滚版本非常方便写论文截图的时候还能找回早期接口设计的改动记录。2.2 数据库设计与核心表结构勤工俭学系统数据库怎么设计直接决定后面开发流程顺不顺。我第一版表建了十几张后来发现很多字段冗余逻辑混乱花了整整一晚上重构。最终稳定下来的核心表大概是这些表名核心作用关键字段user用户表三种角色用 role 字段区分username, password, role, real_name, phoneposition勤工俭学岗位表title, description, department_id, headcount, status, salary_hourapplication学生申请记录student_id, position_id, status, apply_time, remarkattendance工时签到/考勤记录student_id, position_id, work_date, hours, confirm_statussalary月工资结算表student_id, month, total_hours, total_amount, statusdepartment用工部门表name, contact_person, contact_phone角色字段我直接用role字符串区分student、employer、admin没有单独建权限表。因为系统最多 3 种角色权限控制通过后端拦截器按角色校验就能解决。如果角色数量真的多到要动态配置再考虑 RBAC 表但毕设场景真没必要。这里要专门提一个容易踩的坑password 字段一定要存加密后的结果不要用明文。我用的 BCrypt 加密Spring Security 自带的BCryptPasswordEncoder可以直接用。另外一个坑是时间字段工资结算按“月”统计我建议在salary表里直接用month字段存类似2025-06的字符串清晰又方便分组查询别非用datetime加上一堆日期函数去处理。3. 后端核心功能实现细节3.1 登录鉴权与三端角色控制登录是第一个要写的接口也是很多同学代码混乱的重灾区。我采用的方案是 JWT 自定义拦截器没有引入完整的 Spring Security因为学习成本和配置成本加起来对毕设来说偏重。用户登录成功后后端生成一个 token 返回给前端前端每次请求都把它放在请求头Authorization里。后端写一个拦截器统一解析 token并把当前登录用户信息放到ThreadLocal里这样后续业务代码想取用户 ID 就很方便。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { throw new BusinessException(401, 未登录); } // 解析 token获取用户信息并存入 UserContext LoginUser user JwtUtil.parseToken(token); UserContext.set(user); return true; } }角色的接口权限控制我在方法上自定义了一个RequireRole(admin)注解拦截器里判断当前用户角色是否匹配不匹配直接返回“无权限”。这种做法的好处是代码写起来直观论文里也好解释——登录认证管“你是谁”角色校验管“你能做什么”。有个细节值得留意要预留一个“游客也能浏览岗位”的接口。很多同学一上来就把所有接口都锁住了结果学生想看看岗位列表还得先注册登录非常反人类。我在设计接口时岗位列表接口允许匿名访问但申请、审核、考勤这些操作必须登录。3.2 岗位发布与申请流程的稳定性设计岗位发布后学生提交申请这里最容易出现的问题是“超招”——岗位只剩 1 个名额30 个学生同时提交申请结果录取了十几个人。我在第一版代码里也犯了这个错误申请接口逻辑是先查剩余名额大于 0 就插入申请记录。在高并发场景下两个请求同时查到剩余名额等于 1都会插入记录数据一致性就出问题了。解决办法有两种。简单方案是 MySQL 的行锁在position表更新时用UPDATE position SET remaining remaining - 1 WHERE id ? AND remaining 0如果影响行数为 0说明名额已满直接返回“岗位已满”。另一个方案是给application表加唯一约束比如(student_id, position_id)联合唯一从数据库层面防止一个学生对同一岗位重复申请。两种方案最好都做双保险。这个细节写进论文“系统优化与并发控制”里绝对是个加分项。申请被审核通过后学生的状态变为“已录用”此时可以关联attendance表开始记录工时。这里我踩过一个小坑有些岗位的负责人有权直接录用学生有些岗位必须管理员统一分配。我的做法是在position表加了一个hire_mode字段self表示用工部门自行录用admin表示管理员分配。后端判断这个字段再决定是否允许用工部门操作审核接口避免权限越界。3.3 工时登记与工资结算逻辑工时这块我刚开始想得太复杂又是排班表又是签到二维码后来发现以毕设的规模考勤记录把“学生填报、用工单位确认”这个闭环做好就够了。学生登录后可以对已录用的岗位提交每天的工作时间段和工作时长用工单位负责人看到待确认记录核对后点击确认。只有“已确认”状态的工时才会进入工资计算的待选数据。工资结算是一个定时任务也可以用管理员手动触发。如果只是毕设没必要上 xxl-job 这种分布式任务调度框架直接在系统启动时跑一个Scheduled(cron 0 0 2 1 * ?)每月 1 号凌晨两点定时扫描上个月的已确认工时汇总后写入salary表。计算公式很简单总工资 总工时 × 岗位对应的小时单价。需要注意的是一天最多 8 小时普通人不会被允许写代码时要对hours字段做上限校验。这个定时任务在论文里是个很自然的“系统亮点”可以配合图表展示工资流程。我在答辩时被问到“如果月初任务执行失败怎么办”准备的是两个答案一是任务执行前查询当月工资是否已生成避免重复二是失败后管理员可以在页面上手工触发“重新结算”相当于一个兜底策略。这样回答老师基本会点头。4. Vue 前端开发与联调实践4.1 前端工程结构与路由设计前端我使用的是 Vue 3 加 Vite状态管理用 Pinia。写页面之前先规划路由。因为系统有三种角色页面之间的跳转和访问权限要提前想清楚。我的路由设计大概是/login为登录页/student/dashboard为学生工作台/employer/jobs为用工部门岗位管理/admin/users为用户管理。每个人主页是不同路径不完全依靠菜单隐藏来限制页面访问。另外用了 Vue Router 的全局前置守卫在跳转前读取本地存储的 token 和角色信息router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() } else if (!token) { next(/login) } else { next() } })路由守卫可以保证没登录的人进不去页面但这只是前端体验层面的限制真正的安全校验还是在后端做。写论文的时候必须把这个思路讲清楚前端路由控制是为了用户友好后端接口鉴权才是安全底线。有些同学只做了前端拦截后端接口裸奔答辩时被追问“一个懂技术的学生直接发请求怎么办”就答不上来了。Vue 版本方面我用的选项式 API后来也接触了组合式 API。如果是刚入门选项式更直观data、methods、computed丢进去就能跑。组合式 API 更适合逻辑复用要求高的项目。这个选择在论文里也可以稍微提一句体现你了解 Vue 3 两种写法的区别和取舍。4.2 请求封装、拦截器与接口联调前端和后端联调阶段最容易出问题的不是接口逻辑本身而是请求封装的统一性。我把 axios 封装成一个全局实例设置了baseURL为/api然后加请求拦截器自动在 header 中带上 token加响应拦截器统一处理后端返回的数据格式。service.interceptors.response.use( (response) { const res response.data if (res.code 200) { return res.data } if (res.code 401) { router.push(/login) return Promise.reject(new Error(登录过期)) } ElMessage.error(res.msg) return Promise.reject(new Error(res.msg)) }, (error) { ElMessage.error(网络异常) return Promise.reject(error) } )有一类问题非常常见后端返回的数据字段是下划线命名如student_id前端 JS 却习惯用驼峰studentId。如果不想前端到处转字段可以在后端统一加 Jackson 配置把下划线转驼峰。但我的习惯是前端主动适配后端字段规范的接口文档比任何转换配置都可靠。推荐大家用 Apifox 管理接口定义好每个接口的地址、参数、返回示例前端照着文档开发效率能翻倍。联调遇到跨域问题也算家常便饭。开发环境我用 Vite proxy 代理解决生产环境用 Nginx 反向代理把相同域名的/api请求转发到后端服务端口。只要不出现“后端响应了但前端访问不到”的怪问题跨域就基本不会拖太久。5. 毕业论文写作、答辩与常见问题5.1 论文结构安排与图表呈现毕设论文和开发文档完全是两回事它要求的是一条清晰的“提出问题—分析问题—解决问题—验证方案”主线。我的论文大纲可以给大家参考第一章绪论写背景和研究意义、国内外现状第二章相关技术介绍每项技术写清楚版本号和它在这个项目中解决的特定问题第三章系统分析包含可行性分析、功能需求分析、用例图、非功能需求第四章系统设计包含整体架构图、功能模块设计、数据库 ER 图、核心表结构第五章系统实现按角色或模块贴关键代码截图并解释设计意图第六章系统测试写功能测试用例设计和测试结果最后是总结与展望。图表比文字重要得多。实体关系图、系统架构图、用例图、时序图、状态图哪怕画得不复杂也要保证逻辑正确。最忌讳的是论文里用了网上扒下来的课程设计架构图又跟自己系统完全对不上。画图工具用 ProcessOn 或者 draw.io 都行。截代码图时不要整页贴贴关键方法的核心逻辑配 3 到 5 句解释比堆一大篇代码更有说服力。答辩时大概率被问的问题系统有哪些角色、权限是怎么控制的、数据库表之间什么关系、并发申请怎么处理、如何处理数据安全性、前后端如何通信。这些只要你真的是自己一步步调出来的基本都能接住。怕的是只把别人代码跑起来数据字典都说不清一追问就露馅。5.2 高频问题排查与避坑清单开发中我记录了不少代表性的报错在这里列一个速查表方便大家直接对照排错现象常见原因处理方法前端请求 404后端接口路径 RequestMapping 写错或前端 baseURL 不对先看浏览器 Network 里实际请求的 URL和后端控制台日志对照插入数据库中文乱码数据库连接未指定 UTF-8 编码或库表排序规则不对确保 JDBC URL 加characterEncodingutf8建库用 utf8mb4登录后请求 401token 过期或拦截器没有放行预检 OPTIONS 请求拦截器里先放行 OPTIONS再检查 token 解析逻辑前端报跨域本地开发端口和接口端口不一致用 Vite proxy 或在后端加 CORS 配置类上传图片后访问不了静态资源路径映射没配置WebMvcConfigurer 里 addResourceHandlers 指向本地目录有些同学会遇到一个特别恼火的问题项目在自己电脑上跑得好好的换一台电脑就废了。多半是环境变量问题。这里多说一句Java 环境配置时JAVA_HOME 要指向 JDK 安装目录PATH 里加%JAVA_HOME%\bin不要直接写死某个磁盘路径。以后换电脑重装环境会省很多事。还有一个我在测试阶段发现的隐藏 bug学生退出登录以后再换个账号登录页面居然还显示了上一个账号的申请记录。原因是前端用了 Pinia 存储状态退出登录时只清了 token没有清用户信息。后来我统一封装了一个logout()方法token 和用户信息一并清除并跳转登录页。这种“小但影响体验”的问题特别值得写进论文测试章节作为功能测试发现并解决的典型案例。最后再分享一点个人体会做这种管理系统真正费时间的不是写代码而是需求和数据设计。前期跟学校勤工助学相关老师聊清楚流程把表结构设计对了后面写代码就是往框架里填东西的事情。我后来为了论文里能画几张像样的时序图又把核心流程用代码重新走了一遍发现“自己写的东西自己讲清楚”这件事反而比写代码本身更能提升对系统的理解。希望你们做这个题目时也能有同样的收获。本文还有配套的精品资源点击获取