做计算机毕业设计，选“springboot毕业生就业数据填报小程序”这类题目的人特别多。这个题看着简单，实际做起来比想象中复杂得多——它不是一个普通的增删改查，而是一个带审核流程、多角色权限、统计汇总的数据收集系统。我从头到尾把这个项目拆一遍，包括需求分析、数据库设计、接口规划、小程序前端实现，再到答辩时老师最爱问的问题，一次性讲清楚。
1. 需求拆解：毕业生就业填报到底在填什么数据
1.1 业务场景还原
每年毕业季，学校就业办都要统计毕业生的去向。真实场景是这样的：毕业生登录系统，填写自己的就业状态——是签了协议、劳动合同，还是自主创业、灵活就业，或者升学、入伍了。填完之后，辅导员需要在后台审核，确认学生填的信息真实有效。院系管理员要看本院的统计情况，学校就业办要汇总全校数据，最后还要按院系、按专业、按就业类型出报表上报。
这个过程有三个核心痛点。第一是纸质表格效率低，学生填完辅导员收齐再手工录入Excel，信息滞后且容易出错。第二是版本混乱，学生改了一次就业单位，老师手里的Excel还是旧版。第三是统计口径不一致，有人按“协议就业率”算，有人按“总就业率”算，最后数据对不上。
所以这个系统的本质，不是“填个表”，而是一个带状态流转、多角色协同、按权限聚合统计的数据管理平台。想清楚这一点，下面所有设计都会围绕它展开。
1.2 功能清单与角色权限
系统分两端：微信小程序端给毕业生用，后台管理端（Web）给辅导员、院系管理员、学校就业办用。
小程序端核心功能：
- 微信授权登录，绑定学号
- 就业信息填报、修改、撤回
- 查看审核进度与驳回原因
- 接收填报提醒通知
- 证明材料拍照上传
管理端核心功能：
- 毕业生名单管理（支持Excel批量导入）
- 就业信息审核（通过/驳回，填写驳回理由）
- 按学院、专业、班级多维度统计
- 就业数据导出（Excel）
- 填报批次配置（开启/截止时间）
角色权限用表格拆开看：
| 角色 | 数据范围 | 核心操作 |
|---|---|---|
| 毕业生 | 本人 | 填报、修改、查看进度 |
| 辅导员 | 所带班级 | 审核、催报、导出本班数据 |
| 院系管理员 | 本院所有专业 | 查看统计、导出本院数据 |
| 学校就业办 | 全校 | 全局统计、批次管理、名单导入 |
1.3 技术选型：为什么是Spring Boot + 小程序
后端选Spring Boot，理由很直接。它是Java领域目前生态最完整的框架，自动装配机制让你写很少的配置就能跑起一个Web服务。你只需要引入一个spring-boot-starter-web依赖，内嵌Tomcat、DispatcherServlet这些东西框架都自动配好了，不用像早期SSH时代写一堆XML。
前端选微信小程序而不是App或Web，是因为微信生态天然适合这种场景——学生天天用微信，打开小程序就能填，不用额外装App。开发上小程序也简单，WXML+JS+WXSS三件套，加上微信官方组件库，比iOS/Android双端开发成本低得多。如果你熟悉Vue，也可以用uni-app那套，一套代码编译到微信、支付宝等多端，但毕设场景我建议直接用微信原生语法，答辩时更好解释，调试也少一层编译问题。
数据库用MySQL + MyBatis Plus。MyBatis Plus是MyBatis的增强工具，单表CRUD不用写SQL，自带分页插件和条件构造器，能省大量重复工作。对毕设来说，这个组合够用且稳定。
2. 后端设计：数据库表结构与接口规划
2.1 数据库设计——一个毕业生多条记录怎么设计
这是整个项目最核心的环节。先说结论：就业信息主表存“档案”，审核记录表存“过程”。
我一直强调一个设计原则：用户会修改数据，但你不能丢了修改记录。毕业生填错了就业单位，改一次没问题，但如果只做UPDATE覆盖，后面统计口径对不上或者有人质疑数据时你根本说不清。所以需要两张表配合。
学生信息表（student）：
id主键student_no学号（唯一索引）name姓名college_id学院IDmajor_id专业IDclass_name班级phone手机号openid微信openid（绑定后写入）gmt_create、gmt_modified时间字段
就业信息表（employment_info）：
id主键student_id关联学生IDemployment_type就业类型（字典编码：协议就业/劳动合同/自主创业/灵活就业/升学/应征入伍/暂不就业）company_name单位名称company_code统一社会信用代码job_title岗位salary薪资province、city、district单位所在地start_date入职时间proof_url证明材料路径remark备注status审核状态（0草稿 1待审核 2通过 3驳回）batch_id填报批次ID
审核记录表（audit_record）：
idemployment_id关联就业信息IDauditor_id审核人IDaction动作（submit/approve/reject）reason驳回原因或审核意见create_time
这里再补充一个填报批次表（batch）。为什么要这个表？因为学校就业统计是按批次来的，比如“春季批次”和“秋季批次”。批次表里放start_time、end_time、status，小程序端在非填报时间就锁定表单。这个设计在毕设答辩时很加分，说明你考虑了真实业务约束。
2.2 数据字典：不要硬编码就业类型
很多初学者会把就业类型写死在代码里：if (type == 1) { //协议就业 }。这是个大坑。学校过一年可能就调整“就业类型”，比如“第二学士学位”也算一种去向，你写死就只能改代码重新发版，小程序还要走微信审核。正确做法是做一张数据字典表：
CREATE TABLE dict_item ( id INT PRIMARY KEY, dict_type VARCHAR(50) NOT NULL COMMENT '字典类型编码', item_key INT NOT NULL COMMENT '字典项值', item_value VARCHAR(100) NOT NULL COMMENT '字典项文本', sort_order INT DEFAULT 0, status TINYINT DEFAULT 1 );需要就业类型列表时，接口直接查dict_type = 'employment_type'的记录返回给前端渲染。要加类型，后台插入一条记录就行，前后端代码都不用动。这种设计在任何管理类系统里都通用，记住这个思路，你以后做别的项目也用得上。
2.3 后端接口规划与关键实现
接口按RESTful风格设计，核心接口如下：
| 模块 | 方法 | 路径 | 说明 |
|---|---|---|---|
| 登录 | POST | /api/auth/login | wx.login获取code，后端换openid |
| 填报 | POST | /api/employment/save | 保存（草稿/提交） |
| 填报 | PUT | /api/employment/update | 修改已驳回或草稿数据 |
| 填报 | GET | /api/employment/detail | 获取当前学生填报详情 |
| 审核 | GET | /api/admin/audit/list | 待审核列表（分页） |
| 审核 | POST | /api/admin/audit/approve | 通过 |
| 审核 | POST | /api/admin/audit/reject | 驳回（必填原因） |
| 统计 | GET | /api/admin/stat/overview | 总体统计 |
| 统计 | GET | /api/admin/stat/byCollege | 按学院统计 |
| 导出 | GET | /api/admin/export | 导出Excel |
登录这块要讲清楚原理。小程序端调wx.login()拿到一个临时code，传给后端，后端拿着code + AppID + AppSecret去微信接口换openid和session_key。openid是用户在小程序里的唯一标识，但你不能用openid直接当用户身份，因为学生和微信不是实名绑定的。所以要做二次绑定：第一次登录后弹出绑定页，让学生填学号和姓名，后端校验匹配后把openid写到学生表的openid字段。
后续请求的身份认证，我推荐用JWT。登录成功后后端生成一个token返回给小程序，小程序每次请求带上Authorization: Bearer <token>。后端通过拦截器解析token，从Claims里取出用户ID。注意两点：token设置过期时间（建议2小时），过期后小程序端收到401就自动跳转重新登录。
2.4 防重复提交与幂等设计
这个细节很多毕设没有，但真实系统必须有。毕业季学生集中填报，网络波动时小程序可能连发两次提交请求，如果没有幂等机制，数据库就会出现两条重复记录。
我的做法是：Redis里存一个幂等键。小程序提交时生成一个requestId（UUID），后端发现Redis里已有这个key就拒绝重复提交，第一次提交成功后删除key。简单可靠：
@PostMapping("/save") public Result save(@RequestBody EmploymentSaveDTO dto) { String requestId = dto.getRequestId(); if (stringRedisTemplate.hasKey(requestId)) { return Result.error("请勿重复提交"); } stringRedisTemplate.opsForValue().set(requestId, "1", 10, TimeUnit.MINUTES); // 业务处理... return Result.success(); }注意先检查再写入这一步要保证原子性，建议用setIfAbsent而不是先hasKey再set，这样并发场景不会穿帮。
3. 小程序端：填报体验与前后端联调
3.1 小程序端页面结构与登录绑定逻辑
小程序端页面我拆成四块：登录页、填报页、进度页、我的页面。
登录页面是用户看到的第一屏。流程是这样：onLoad时调wx.login拿到code，发给后端/api/auth/login，后端返回hasBound标志。如果没绑定，跳转绑定页填学号姓名；已绑定就直接进首页。这个绑定动作理论上只做一次，后续静默登录即可。
这里有个坑要提醒：不要在小程序端把用户填的学号和姓名只存本地Storage就完事，后端必须再次校验学号姓名是否存在且匹配。我见过有同学图省事，前端判断一下“填了就通过”，后端完全不校验，结果随便谁都能绑定别人的学号，数据就乱了。
3.2 填报表单的动态联动设计
填报页是整个系统的核心交互。表单不是一成不变的，就业类型不同，要填的内容完全不同：选了“自主创业”，要填创业项目名称、注册地；选了“升学”，要填录取学校、专业；选了“应征入伍”，填入伍地就行。全部字段堆在一个页面里，体验就是灾难。
我的做法是：后端根据已选的employment_type返回该类型需要展示的字段配置，前端拿到配置动态渲染表单。简单版本可以用wx:if在前端控制显示；更工程化的做法是后端配置“字段模板”，返回JSON数组，前端用循环渲染。毕设做到前端条件判断的程度就够了，但答辩时能说出“动态表单按就业类型驱动”这个思路，会显得你的设计更有层次。
字段校验放在前后端两层。前端保证响应速度，后端保证数据安全。以统一社会信用代码为例，前端用正则校验18位字符，后端再做一次算法校验（校验位规则）。电话号、邮箱同理。薪资字段如果填的是数字，前端要限制输入类型，后端用Range注解校验范围。
3.3 省市区级联选择与证明材料上传
单位所在地用省市区三级联动。国产的w-picker组件或者直接用picker模式嵌套都行。注意一个体验细节：用户改了省份之后，城市和区县要清空重置，不能让用户选了一个城市的旧值还挂在另一个省份下面。这个低级Bug我在不少线上系统里见过，自查时重点盯。
证明材料上传走微信的wx.chooseMedia选图片，然后wx.uploadFile传到后端。后端接文件后存本地磁盘或对象存储。建议在服务端把文件路径和访问URL返回给前端，前端回显用URL拼上服务端地址。文件名生成规则别用原始文件名，用UUID+后缀，防止中文名乱码和重名覆盖：
String suffix = file.getOriginalFilename().substring(...); String newName = UUID.randomUUID().toString().replace("-", "") + suffix;3.4 前后端联调：request封装与本地调试
小程序端需要一个统一的请求封装。核心逻辑就几件事：公共header带上token、超时设置、HTTP状态码处理、业务状态码统一抛错、401自动跳登录页。
const request = (url, method, data) => { return new Promise((resolve, reject) => { wx.request({ url: baseUrl + url, method, data, header: { 'Authorization': 'Bearer ' + wx.getStorageSync('token'), 'Content-Type': 'application/json' }, timeout: 10000, success(res) { if (res.statusCode === 401) { wx.navigateTo({ url: '/pages/login/index' }); reject(res); } else if (res.data.code === 200) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(res); } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); };本地调试最麻烦的是域名校验。小程序真机预览时，request的域名必须是HTTPS且在小程序后台配置过白名单。开发阶段有两个变通办法：一是在微信开发者工具里勾选“不校验合法域名”，局域网IP（如http://192.168.x.x:8080）可以直接调；二是用内网穿透把本地服务暴露成公网地址，方便真机测试。注意正式发布前必须在后台配置合法的HTTPS域名。
4. 核心统计模块：SQL与聚合逻辑
4.1 统计模块与展示设计
统计是就业系统最亮眼的部分，也是毕设答辩的加分项。需求方要看的核心指标：总填报人数、各就业类型占比、学院填报率、专业就业率。
填充率怎么算要提前想明白。分母是毕业生名单总人数，分子是状态为“已通过”的人数。注意不要用全部提交数做分子，因为待审核的数据还没确认，口径不对。
我提供了一个典型统计接口的设计实现。按就业类型统计时用一条SQL搞定：
SELECT SUM(CASE WHEN employment_type = '1' THEN 1 ELSE 0 END) AS protocol_count, SUM(CASE WHEN employment_type = '2' THEN 1 ELSE 0 END) AS contract_count, COUNT(*) AS total_count FROM employment_info WHERE batch_id = #{batchId} AND status = 2动态条件用MyBatis Plus的QueryWrapper配合groupBy也行，但复杂统计建议手写SQL放在Mapper.xml里，可读性和性能都更好。
图表展示可以利用ECharts的微信小程序版ec-canvas组件，将统计数据渲染成饼图和柱状图。圆环图显示就业类型占比，柱状图显示各学院填报率对比，视觉效果比干巴巴的数字好太多，答辩时给老师演示一下很加分。
4.2 统计报表数据一致性校验
统计最容易出的bug是数据对不上。比如按学院统计时，有的学生college_id是空的；有的就业信息表里存在多条记录（学生改过），如果不加限制就重复计数。
我的排查思路是：定好唯一规则——每个学生每个批次只能有一条“有效记录”。这里可以用student_id + batch_id做唯一索引，数据库层面防住重复。有效记录的判定就是status = 2（审核通过）。所有统计SQL都统一加这两个过滤条件。这样不管学生改了多少次，统计结果都是稳定的。
校验逻辑一定要用数据自检。比如“待审核数 + 通过数 + 驳回数 + 草稿数”应该等于“该批次填报总数”，总数又应该等于“毕业生名单数 - 未填报数”，这些对账SQL写完统计模块后跑一遍，能发现很多隐藏问题。
5. 毕设过程中踩过的坑与排查技巧
5.1 Spring Boot版本与环境的坑
近几年Spring Boot版本迭代快，很多同学一打开IDEA新建项目默认就是3.x版本。但Spring Boot 3.x要求JDK 17+，如果你电脑上还是JDK 8，项目根本起不来。我建议毕设直接用Spring Boot 2.7.x + JDK 8的组合，原因很简单：稳定、教程多、你搜索到的代码示例大部分都能直接用。Spring Boot 3.x有个大坑是javax包名改成了jakarta，早期的参考代码直接复制过来会全部报编译错误。
另一个高频问题是项目启动报Port 8080 was already in use。这不是Bug，是你之前启动的进程没关干净。排查方法：Windows下用netstat -ano | findstr 8080找到PID，然后taskkill /PID 进程号 /F；Mac/Linux下用lsof -i:8080。比改端口好，因为改端口后面小程序端baseUrl也得跟着改。
5.2 小程序审核与真机兼容的坑
小程序开发完要发布必须过微信审核。审核最常见的被拒理由是“类目与所选服务类目不一致”。毕业生就业填报可能涉及教育或招聘类目，发布前提前在微信公众平台把服务类目选对。还有就是涉及用户个人信息收集，必须在小程序隐私保护指引里声明收集哪些信息、用途是什么。这个不配好审核必被拒。
真机测试时注意安卓和iOS的兼容。一个典型的坑是wx.uploadFile在iOS上对filePath参数的要求较严格，如果你拿到的临时文件路径不对会上传失败；另一个是底部安全区的问题，iPhone X之后机型有底部小黑条，页面底部按钮要用env(safe-area-inset-bottom)适配，不然“提交”按钮会被挡住。
5.3 毕业设计答辩高频问题速查
答辩老师通常不会逐行读代码，但一定会问几个验证“这项目是不是你做的”的问题。我把高频问题整理如下：
Q1：为什么选择Spring Boot？答：Spring Boot通过自动配置简化了SSM时代的繁琐配置。核心原理是启动类上的@SpringBootApplication注解组合了@EnableAutoConfiguration、@ComponentScan等，框架通过spring.factories加载AutoConfiguration类，配合@ConditionalOnClass等条件注解按需装配Bean。体现在本项目中，我引入starter-web就自动获得内嵌Tomcat和Spring MVC能力，引入mybatis-plus-boot-starter就自动配好数据源和MyBatis。
Q2：你的项目权限是怎么控制的？答：后端用Spring MVC拦截器校验JWT，登录用户身份保存在token里。请求到达Controller前，拦截器解析token并存入ThreadLocal，业务层根据当前用户角色ID判断操作权限。辅导员、院系管理员、就业办admin分别对应不同数据范围，通过角色和学院ID联合过滤。
Q3：审核流程的状态是怎么设计的？答：用一个枚举类定义状态流转：草稿（0）可以修改和提交；待审核（1）不可修改，只等审核；审核通过（2）流程结束；驳回（3）可修改后重新提交，状态回到待审核。状态流转只能按既定方向执行，非法跳转直接抛异常。核心数据校验规则放在后端，因为小程序端校验可以绕过，后端必须重新校验。
Q4：如果毕业季5000人同时填报，你的系统扛得住吗？答：毕设层面主要做了三件事：数据库字段和索引设计合理（唯一索引防重复、组合索引覆盖查询）；接口做了幂等控制防重复提交；前端做了防抖，避免连点。如果要真正扛高并发，可以引入消息队列削峰，数据库层面做读写分离，这些作为扩展点写进了论文。
Q5：就业证明材料怎么防止被篡改？答：目前方案是把材料存到文件服务器，数据库只存路径。如果要增强安全性，可以在上传时计算文件的MD5值存入数据库，审核时可以比对校验。这个场景也可以用MinIO这类对象存储，配置简单，自带访问控制。
5.4 论文与答辩演示建议
论文结构跟着项目走，题目直接叫“基于Spring Boot的毕业生就业信息管理小程序设计与实现”就行。摘要部分说明对象、方法、技术、结果；绪论写背景与意义、国内外现状；核心技术部分讲Spring Boot自动配置原理、MyBatis Plus、JWT、微信小程序框架；系统设计讲需求分析、功能模块、数据库设计、接口设计；实现部分按模块截图+核心代码讲解；最后结论写不足与展望。
答辩演示时准备一个“演示脚本”：先登录页走微信授权绑定学号，填一份就业信息提交，切到管理后台通过审核，再回统计页看数据变化。演示时把接口日志一起展示，能证明你前后端是自己联通的。再把数据字典表加一条记录，刷新页面看选项变化，这一手基本能震住全场。
写在最后
这个项目的完整源码其实不难，难的是把业务逻辑想透彻。我做毕设指导时反复和学生强调：不急着写代码，先在纸上把角色画出来、把状态流转写清楚、把表字段列全。后端Spring Boot给你省了大量配置时间，你省下来的精力就该花在业务设计上。毕业生就业填报这种题材，天然就是一个小而全的信息系统，用它练手，审核流、权限、统计、文件、微信生态全都覆盖到了，做完这一套，你毕业之后做任何管理类系统都会有底气。
