Spring Boot + Vue 全栈开发勤工俭学系统：毕设避坑指南

简介：这是一份面向高校计算机相关专业毕业设计的完整论文文档，主题为校园勤工俭学兼职系统。系统基于B/S架构，采用Java、Spring Boot框架，搭配Eclipse、Maven、Mariadb 10.5和Tomcat 8.5等主流工具，前端使用HTML5与CSS3，论文中详细阐述了项目背景、技术选型、系统设计与实现过程，适合正在准备毕设或希望了解前后端分离开发流程的读者参考。资源包仅包含1个docx文件，大小约6.17MB，文件结构完整，除了中英文摘要、目录、绪论外，还覆盖了需求分析、数据库设计、功能模块划分等毕业设计关键章节。该论文结构清晰、内容翔实，有助于快速理解校园兼职系统从需求到落地的完整流程，并为同类管理系统的设计与论文写作提供有价值的借鉴。已有158人学习过。 毕设题目前面加上“java+vue+springboot”三个词，看着像任务书里拼出来的，但真把这套技术栈做完还写成论文的，多少都得脱层皮。我去年拿的就是这个题目，从需求分析、数据库设计、后端接口、前端页面，到最后定稿查重和答辩，前后扎扎实实折腾了将近三个月。这篇文章把我踩过的坑和总结出来的做法一次性说清楚，包括选型逻辑、核心模块怎么落地、论文章节怎么安排、答辩时容易被问什么，以及一些调试到半夜才发现的鬼问题。准备做同类系统的同学，或者想用 Spring Boot + Vue 练一个完整全栈项目的朋友，这篇应该能帮你们少走不少弯路。

1. 项目背景与整体设计思路

1.1 勤工俭学业务的真实痛点

校园勤工俭学这件事，看起来就是“发岗位、学生报名、老师审核、月底算钱”，但真正走一遍线下流程就知道有多乱。我前期调研了学校资助中心的实际工作方式，发现他们主要靠微信群发 Excel 表格收集报名，学生提交申请表后再人工汇总，岗位信息散落在各条聊天记录里，学生根本不知道哪些岗位还没招满。用工部门想发布需求要先找老师要模板，月底统计工时更是灾难，纸质单据经常对不上。

所以这个系统的核心价值不是“有个网站能登录”，而是把一条完整业务链搬到线上：管理员发布勤工俭学岗位、学生浏览和申请、用工单位或管理员审核、录用后登记考勤工时、月末按工时结算补贴、学生随时查自己的工资记录。除了学生和管理员这两个最明显的角色，系统还要考虑“用工部门”的诉求。食堂、图书馆、行政办公室这些部门人员情况不一样，有的希望自己审核简历，有的希望直接由资助中心统一分配，权限设计上就得留出灵活度。

1.2 为什么是 Java + Vue + Spring Boot

选这套技术栈不是因为它时髦，而是因为它资料多、生态成熟、出问题搜得到答案。Java 作为后端主力语言，学校课程里教过 JavaWeb 和 SSM，Spring 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 数据库设计与核心表结构

勤工俭学系统数据库怎么设计，直接决定后面开发流程顺不顺。我第一版表建了十几张，后来发现很多字段冗余，逻辑混乱，花了整整一晚上重构。最终稳定下来的核心表大概是这些：

角色字段我直接用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 高频问题排查与避坑清单

开发中我记录了不少代表性的报错，在这里列一个速查表，方便大家直接对照排错：

有些同学会遇到一个特别恼火的问题：项目在自己电脑上跑得好好的，换一台电脑就废了。多半是环境变量问题。这里多说一句：Java 环境配置时，JAVA_HOME 要指向 JDK 安装目录，PATH 里加%JAVA_HOME%\bin，不要直接写死某个磁盘路径。以后换电脑重装环境会省很多事。

还有一个我在测试阶段发现的隐藏 bug：学生退出登录以后，再换个账号登录，页面居然还显示了上一个账号的申请记录。原因是前端用了 Pinia 存储状态，退出登录时只清了 token，没有清用户信息。后来我统一封装了一个logout()方法，token 和用户信息一并清除并跳转登录页。这种“小但影响体验”的问题特别值得写进论文测试章节，作为功能测试发现并解决的典型案例。

最后再分享一点个人体会：做这种管理系统，真正费时间的不是写代码，而是需求和数据设计。前期跟学校勤工助学相关老师聊清楚流程，把表结构设计对了，后面写代码就是往框架里填东西的事情。我后来为了论文里能画几张像样的时序图，又把核心流程用代码重新走了一遍，发现“自己写的东西自己讲清楚”这件事，反而比写代码本身更能提升对系统的理解。希望你们做这个题目时也能有同样的收获。

本文还有配套的精品资源，点击获取