毕业后找工作那会儿，我盯着招聘网站上的岗位列表，突然想到一个问题：学校里的就业信息发布，大多还是靠辅导员转发群消息、学院官网贴公告，学生和企业之间隔着好几层。后来做毕业设计，我决定直接做一个大学生就业招聘系统平台。
这个项目用的是 SpringBoot + Vue 前后端分离架构，附带完整的 SQL 脚本和接口文档，涉及学生、企业、管理员三种角色，覆盖职位发布、简历投递、面试邀请、数据统计等完整招聘闭环。对 Java Web 方向的毕设来说，它覆盖面广、业务逻辑清晰、演示效果直观，而且技术栈足够主流，拿得出手。
这篇文章我会从整体设计、数据库建模、后端核心模块、前端页面实现、接口文档规范到常见坑位，把整个项目拆开讲清楚，适合正在做同类毕设、或者想快速上手前后端分离项目的同学参考。
1. 项目背景与整体设计思路
1.1 这个系统到底解决什么问题
传统的校园招聘流程，信息散落在各个渠道——企业 HR 把职位发给学校就业办，就业办整理成 Excel 发到各学院，辅导员再转发到班级群，学生看到消息后还要自己把简历发到指定邮箱。这个过程至少有三层损耗：信息传递慢、格式不统一、反馈不闭环。
这个系统的核心目标，就是把这些散落的环节集中到一个平台上。企业可以自己注册、发布职位、查看收到的简历；学生可以完善在线简历、浏览岗位、一键投递、查看投递状态；管理员负责审核企业资质、维护基础数据、查看整体招聘数据。三方在同一个平台里完成完整的业务闭环，这就是这个项目最有价值的地方。
1.2 为什么选这个方向作为毕设
毕设选题最怕两件事：一是题目太大做不完，二是题目太小没内容写。就业招聘系统刚好处于一个合适的中间地带——业务路径清晰，角色划分明确，每个角色的功能模块都可以横向扩展。
比如学生端可以扩展简历模板、面试记录、收藏职位；企业端可以扩展在线测评、批量筛选简历；管理员端可以扩展数据报表、操作日志。这意味着你在开题报告里写的每一项研究内容，都能在系统里找到对应的落地实现，答辩的时候有东西可讲，而不是停留在概念层面。
另外一个实际考量是，招聘系统天然适合展示前后端分离的开发模式。企业的职位列表、学生的投递记录、管理员的审核列表，这些都是典型的 CRUD 场景，配合状态流转（投递中、已查看、已邀请、已录用），可以很自然地引入 RESTful API 设计、统一响应格式、请求拦截器等知识点，这些恰好也是面试官爱问的东西。
2. 技术选型与架构设计
2.1 后端技术栈：SpringBoot 2.x 的选择
后端我用了 SpringBoot 2.x 而不是最新的 3.x，这个选择是经过考虑的。SpringBoot 2.7 是目前市面上教程资源最丰富、兼容性最稳妥的版本，很多公司的存量项目也还在这个版本线上跑着。SpringBoot 3.x 要求 JDK 17 起步，虽然新项目用没什么问题，但如果你的部署环境还是 JDK 8，那会遇到不少兼容性麻烦。
具体用到的组件包括：
- SpringBoot 2.7.x：基础框架，快速搭建 RESTful API
- MyBatis-Plus 3.5.x：数据访问层，内置分页插件，代码量比原生 MyBatis 省不少
- MySQL 8.0：数据库，注意 8.0 的驱动类名和 5.x 不一样
- JWT + 拦截器：登录认证，无状态会话管理
- Hutool：工具类库，处理日期、随机数、文件上传都很方便
MyBatis-Plus 这个选择对毕设来说很划算。它内置了常用的增删改查方法，单表操作几乎不用手写 SQL，你只需要把精力集中在多表关联和业务逻辑上。给导师演示的时候，分页查询是加分项，MyBatis-Plus 的分页插件一行配置就能搞定，比手写 PageHelper 要省事。
2.2 前端技术栈：Vue 2.x 还是 Vue 3.x
前端框架我纠结过 Vue 2 还是 Vue 3。最终选了 Vue 2.7 + Element UI 的组合，原因很现实：Element UI 对 Vue 2 的生态已经非常成熟，你随便搜一个问题，Stack Overflow 和掘金上基本都有现成答案。如果你的基础是跟着网课学的 Vue 2，那继续用 Vue 2 做毕设是阻力最小的路径。
Vue 3 + Element Plus 当然也可以，而且更适合长远发展。但要注意 Element Plus 的组件 API 和 Element UI 有一些差异，比如el-dialog的visible.sync变成了v-model，如果中途切换，调试成本会明显增加。我的建议是：选你熟悉的那套，然后一条路走到黑，不要在开发中期换框架。
前端其他配套选型：
- Vue Router 3.x：路由管理，实现页面跳转和菜单高亮
- Axios：HTTP 请求库，统一封装请求拦截和响应处理
- ECharts 5：管理员端数据可视化，展示职位分布、投递趋势
- SCSS：样式预处理，嵌套写法更清晰
2.3 前后端分离架构的权衡
前后端分离是这个项目的核心架构。后端只提供 JSON 数据接口，前端负责页面渲染和交互，两者通过 HTTP 协议通信。这样做的好处是开发和部署可以独立进行，前端用 Node 的 dev server 跑在 8080 端口，后端用 SpringBoot 内嵌 Tomcat 跑在 8081 端口，本地开发互不干扰。
跨域问题需要在后端处理。我用了一个CorsConfig配置类，放行了所有来源和方法，同时允许携带 Authorization 请求头。生产环境下这种全放行的配置肯定不安全，但毕设环境下够用，部署到云服务器后，也可以用 Nginx 反向代理来解决跨域，前端请求统一走/api前缀，由 Nginx 转发到后端服务。
3. 数据库设计与 SQL 脚本
3.1 核心数据表设计思路
数据库设计是整篇论文的重要支撑。我建了 8 张核心表，按角色划分清晰：
user：用户表，存储学生、企业、管理员的账号信息，用role字段区分类型student_profile：学生简历表，一对一关联 user 表company：企业信息表，包括企业名称、规模、行业、简介、营业执照图片job：职位表，关联企业，记录岗位名称、薪资、要求、状态resume_delivery：投递记录表，关联学生和职位，记录投递时间、状态interview：面试邀请表，企业对学生发起面试邀请collection：职位收藏表，学生收藏感兴趣的职位admin_log：管理员操作日志表
关键设计点是投递记录表。很多初做这个系统的人会把投递状态直接写死在职位表或者简历表里，这是不对的。投递是一个独立的行为，一个学生可以投递多个职位，一个职位会收到多个学生的简历，这是典型的多对多关系，必须用中间表来维护。resume_delivery表里冗余了delivery_status字段，用 0/1/2/3 表示待查看、已查看、已邀请、已拒绝，这样企业端列表页可以直接按状态筛选，不需要额外关联查询。
3.2 SQL 脚本的导入与初始化
附带的 SQL 脚本是整个项目能跑起来的第一步。脚本一共包含三个部分：建库语句、建表语句、初始数据。数据库名我用的是job_portal，建议你保持统一，不然改配置文件的连接字符串会很麻烦。
用 Navicat 或者命令行导入都可以。命令行导入的方式是：
mysql -u root -p < job_portal.sql导入前注意两点。一是 MySQL 版本，如果你本地装的是 5.7，脚本里的utf8mb4字符集没问题，但如果有ENGINE=InnoDB DEFAULT CHARSET=utf8mb4之外的额外参数（比如ROW_FORMAT），旧版本可能不认。二是初始数据里我放了几个测试账号：一个管理员、两家企业、三个学生，方便拿到项目后立刻登录演示，不用自己一条条造数据。
初始数据的作用不要小看。答辩的时候导师要看效果，你现场临时注册一个企业账号、填一堆资料，体验很尴尬。预置好的数据直接展示列表页、详情页、统计图表，专业感立刻就出来了。
3.3 关键表关系与字段设计细节
用 Navicat 看设计图的话，能更直观地理解表关系。学生表通过user_id和student_profile一对一关联，企业表同理。job表通过company_id关联企业，resume_delivery同时持有student_id和job_id两个外键。collection表也类似。
有两个字段设计上的细节值得提一下。时间字段我统一用datetime类型，而不是timestamp，因为timestamp有 2038 年问题，而且范围受到时区影响。job表里的salary_min和salary_max我没有合并成一个字符串，而是拆成两个整型字段，这样后面前端做薪资区间筛选时可以直接用 SQL 比较大小，如果用字符串存储，筛选条件会写得非常痛苦。
企业资质审核状态我也是用整型，0 表示待审核，1 表示已通过，2 表示已驳回。用数字而不是字符串的好处是，枚举的扩展性更强，而且数据库占用更小。前端拿到数字后，用自定义过滤器映射成对应的文字展示即可。
4. 后端核心功能实现
4.1 登录认证与 JWT 拦截器
登录是整个系统的入口，我用的方案是 JWT + Spring 拦截器，没有引入 Spring Security，原因很简单：Spring Security 的学习成本高，配置复杂，对毕设来说属于过度设计。
用户登录成功后，后端生成一个 token，把userId和role都放进 token 的 claims 里。前端把它存在 localStorage 中，每次请求在 axios 拦截器里放到Authorization请求头。后端的拦截器会统一放行登录接口和注册接口，其他接口全部校验 token，解析失败直接返回 401。
@Component public class JwtInterceptor implements HandlerInterceptor { @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.isEmpty()) { throw new BusinessException(401, "未登录或 token 已过期"); } // 解析 token，把用户信息放入 request 属性 Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } }有了 token 里自带的 userId，后端接口就不需要前端再传用户 ID 了。比如学生投递简历的接口，直接从拦截器设置好的 request 属性里取 userId，再去查对应的学生资料，这样避免了用户伪造 ID 操作他人账号的风险，也省去了不少参数传递。
4.2 学生端：简历管理与投递流程
学生端的核心功能是简历和投递。简历表设计成和教育背景、项目经历分开的形式，但这版为了控制复杂度，我用的是单表存储，字段包括姓名、性别、出生日期、学历、院校、专业、手机号、邮箱、期望城市、期望职位、个人介绍等。这样前端在一个表单里就能完成全部编辑，存储和查询都简单。
投递流程是系统里业务逻辑最完整的一段。学生点击职位详情页的"立即投递"按钮，后端要做三步校验：当前登录用户是否是学生；简历是否已完善（没有完善提示先去完善）；是否已经投递过这个职位（防止重复投递）。校验通过后插入一条resume_delivery记录，状态为 0（待查看）。
@PostMapping("/delivery") public Result delivery(@RequestBody DeliveryDTO dto, HttpServletRequest request) { Integer userId = (Integer) request.getAttribute("userId"); StudentProfile student = studentProfileService.getByUserId(userId); if (student == null) { return Result.error("请先完善个人简历"); } int count = deliveryService.count( new LambdaQueryWrapper<ResumeDelivery>() .eq(ResumeDelivery::getStudentId, student.getId()) .eq(ResumeDelivery::getJobId, dto.getJobId()) ); if (count > 0) { return Result.error("您已投递过该职位"); } // 插入投递记录 ... }投递状态的变化会产生通知。这里我没有引入消息队列或者 WebSocket，而是采用了一个简单方案：企业端进入"收到的简历"列表时，按create_time倒序排列，新的投递自然排在最上面。对于毕设项目，这种实现方式已经能很好地展示业务流转了。
4.3 企业端：职位发布与简历筛选
企业端的核心是职位管理和简历处理。企业登录后，只能看到自己发布的职位，这是通过 MyBatis-Plus 的LambdaQueryWrapper加上companyId条件实现的。发布职位时，后端会校验当前用户角色是否为企业，以及企业资质是否审核通过。
简历处理是企业端最有演示价值的功能。企业打开职位详情，能看到所有投递这个职位的学生列表，点击每条记录可以查看学生简历详情，然后操作"通过"或"拒绝"，对应delivery_status从 1（已查看）变为 2（已邀请）或 3（已拒绝）。
如果通过了，后端会生成一条面试邀请记录，包含面试时间、地点、备注。学生端的"投递记录"页面立刻就能看到状态变化，并展示面试邀请详情。整个流程跑一遍，就是一个完整的业务闭环，这也是答辩时最容易出彩的演示路径。
4.4 管理员后台：审核与统计
管理员端承担了平台的监督职责。核心功能有四个：企业资质审核、职位审核、数据统计、管理员日志。企业注册后，状态默认是待审核，企业发布职位时也会标记待审核，管理员可以在后台选择通过或驳回，驳回时填写原因，企业端登录后可以看到。
数据统计用了 ECharts 展示。后端提供两个统计接口：一个按行业维度统计职位数量（柱状图），一个按时间维度统计投递趋势（折线图）。SQL 上就是简单的GROUP BY加COUNT，配合 MyBatis-Plus 的selectMaps方法来返回列表。前端在管理员首页加载后，调接口拿到数据，用 ECharts 渲染出图表。这两张图放在页面上，整个管理后台的分量就上来了。
4.5 接口统一响应与全局异常处理
这个项目里我把所有接口的返回结果都封装成了一个统一格式，包括状态码、消息、数据三个字段。这样做的好处是前端的 axios 拦截器可以统一判断状态码。业务上还有自己定义的异常和全局异常处理器。
全局异常处理非常值得一做。如果没有它，代码里出现空指针异常时，返回的是 SpringBoot 默认的错误页，前端拿到的是 HTML 内容，调试起来特别痛苦。加上@RestControllerAdvice之后，所有异常都被统一转换成 JSON 响应，同时可以在异常处理器里打日志，方便定位问题。这是整个项目里性价比最高的一个工具，一定不要省。
5. 前端页面与接口联调
5.1 Vue 项目初始化与目录结构
前端我用 Vue CLI 4 初始化项目，目录结构按功能做了划分：
src/ ├── api/ # 接口调用模块，按业务域拆分 │ ├── auth.js │ ├── student.js │ ├── company.js │ └── admin.js ├── router/ # 路由配置 ├── store/ # Vuex 状态管理 ├── views/ # 页面组件 │ ├── login/ │ ├── student/ │ ├── company/ │ └── admin/ ├── components/ # 公共组件 └── utils/ # axios 封装、工具函数api目录的拆分是我觉得前端最值得保持的习惯。每个页面的组件不要直接从views里发 axios 请求，而是通过api模块导出函数，页面只负责调用。比如登录页面调用的是api/auth.js里的login(userInfo)函数，请求 URL 集中管理，后续修改后端路径时只需要改一个地方。
5.2 登录拦截与路由守卫
前端路由守卫实现了页面级别的访问控制。beforeEach里检查localStorage是否有 token，有就放行，没有就跳转到登录页。登录成功后，根据返回的角色字段跳转到对应的首页：学生跳/student/home，企业跳/company/home，管理员跳/admin/dashboard。
这里有个容易踩的坑：路由守卫里不要只判断有没有 token，还要判断 token 是否过期。如果后端返回 401，axios 的响应拦截器应该统一处理，清空本地存储并强制跳回登录页。否则会出现 token 过期但是前端仍然停留在页面里，用户点了任何按钮都会报错，体验很糟。
// axios 响应拦截器 service.interceptors.response.use( response => { const res = response.data if (res.code === 401) { localStorage.removeItem('token') router.push('/login') return Promise.reject(new Error('登录已过期')) } return res }, error => { return Promise.reject(error) } )5.3 列表页与分页组件的实践
列表页是前后端分离项目里最常见的页面类型，企业端的职位列表、学生端的岗位列表、管理员的审核列表都是。前端用 Element UI 的el-pagination组件，把currentPage和pageSize传递给后端接口，后端返回total总数和当前页的记录列表，前端更新表格数据和总条数。
岗位列表页的搜索条件包括关键词、城市和薪资区间。前端把筛选表单绑定的对象作为请求参数传给后端，后端用 MyBatis-Plus 的LambdaQueryWrapper动态拼接查询条件。注意salary_min和salary_max要分开传，后端分别用ge和le方法比较。动态条件查询是高频考点，写的时候要多注意避免空条件导致的查询范围过大问题。
5.4 前后端联调的协作方式
联调阶段最怕的就是接口路径对不上。我提供的接口文档在联调中的核心作用是：定义每个接口的路径、请求方式、请求参数、响应格式。前端同学照着文档写 axios 调用，后端口按文档实现，两边用同一个标准对齐，开个玩笑说这叫"按文档办事"。
实际开发中，接口文档不是一次写死的，往往需要沟通调整。比如我原本设计的投递接口是 POST 请求，参数是{studentId, jobId}，但后来发现学生 ID 可以从 token 里取，于是改成了{jobId}，前端自动就从 9 变成了 8 个参数。这种调整记录下来，最终版接口文档就是答辩时最好的技术产出之一。
6. 接口文档与系统测试
6.1 接口文档的规范与示例
这套接口文档我用的是 Markdown 格式，按角色模块分成几部分：公共接口、学生端接口、企业端接口、管理员接口。每个接口包含字段说明、请求示例、响应示例和错误码说明。
接口文档不是随便写写就行的，它有实际的用处。一是你自己在开发调试过程中，对着文档检查返回给前端的数据结构，能更快发现问题。二是毕设论文里需要附上系统设计说明，接口文档可以直接作为核心内容。三是答辩时有老师问"你觉得这个项目的接口设计有什么特点"，你可以直接引用文档里的统一响应格式和分页参数设计来说明。
一个完整的接口说明大致长这样：
POST /api/auth/login
请求参数：
username：账号（必填）password：密码（必填）role：角色类型，1 学生、2 企业、3 管理员（必填）
响应示例：
{ "code": 200, "message": "success", "data": { "token": "eyJhbGciOiJIUzI1NiJ9", "role": 1 } }6.2 接口权限控制设计
接口权限是整个系统安全性的核心。我采用的是基于角色的拦截器逻辑，根据 request 属性里解析出来的角色，判断能否访问接口。拦截器里做了一层分类：/api/auth/**放行，/api/student/**需要角色为 1，/api/company/**需要角色为 2，/api/admin/**需要角色为 3。
这里有个微妙的问题：投递简历这个动作是学生端发起的，但是企业端也需要查看投递记录。我的方案是路由设计上做了拆分，投递动作放在/api/student/delivery下，查看投递列表放在/api/company/delivery下。按操作者而不是按数据归属来划分接口路径，这样权限控制逻辑就很清晰，每个接口的角色归属没有歧义。
6.3 功能测试与性能注意点
整个系统的联调测试我大约花了两天时间。第一遍主要测功能：注册、登录、发布职位、投递简历、审核通过、数据统计，走通主流程。第二遍测边界：重复投递、未登录访问、错误密码、越权访问。这些问题在第一轮测试中大多数都能发现，发现后第一时间修复并补进接口文档。
性能方面，毕设项目并发量不会太大，但我做了两个优化点：分页查询是必需的，后端所有列表接口都做了分页；图片资源走的是本地存储路径，没有用 Base64 上传到数据库，避免数据库体积过大。如果你部署到云服务器，建议把上传路径单独目录化，配置一个虚拟路径映射，不然项目重新打包后上传的文件会丢失。
7. 常见问题与避坑指南
7.1 环境配置类问题
问题一：SpringBoot 版本太高导致 JDK 版本不兼容。
SpringBoot 3.x 需要 JDK 17，如果你电脑上是 JDK 8，启动时直接报UnsupportedClassVersionError。解决办法是换成 SpringBoot 2.7.x，它兼容 JDK 8。如果你非要尝鲜用 SpringBoot 3.x，那就要先装 JDK 17，并且 IDEA 里的 Project Structure 也要改。
问题二：MyBatis-Plus 分页失效。
分页插件没有生效通常是因为没在配置类里添加拦截器。MyBatis-Plus 3.5 以后，分页需要显式配置MybatisPlusInterceptor，否则Page对象返回的 total 是 0，查询结果还是全量数据。加了配置类以后重启项目就能正常分页。
问题三：接口访问全部 404 或者报 405。
404 大概率是路径写错了，检查 controller 的@RequestMapping路径和前端 api 模块里的路径是否一致。405 是请求方式不匹配，比如后端定义的是 POST，前端用 GET 请求。这类问题靠接口文档就能解决，每个接口都标注清楚方法和路径，对照检查即可。
7.2 业务逻辑类问题
问题四：重复投递导致数据脏。
这个问题的本质是缺少唯一约束。在resume_delivery表设计时，我给student_id + job_id建了唯一索引uk_student_job，虽然代码层也做了校验，但数据库索引是最后一道防线。如果代码逻辑有漏洞，有并发情况出现，唯一索引也能保证不会产生重复数据。
问题五：企业看不到学生投递的简历。
排查思路是检查投递记录里的company_id是否在插入数据时正确保存。如果你在resume_delivery表里没有冗余company_id字段，查询时要通过job表关联企业的 id，SQL 要写对关联条件。建议在业务设计上把company_id冗余到投递记录表，查询时少一层 JOIN，性能更好，逻辑也更直接。
7.3 答辩演示的注意事项
答辩演示是最容易出状况的环节。我的经验是：演示前先把测试数据准备好，登录几个账号都提前把 session 调通；页面打开不要现场挂后台看日志，因为日志刷屏会让人感觉系统不稳定；尽量走通一条"学生投递、企业处理、面试邀请"的完整流程，让导师直观感受到系统的业务闭环。
如果在演示现场遇到接口报错，不要慌，也别去翻日志。直接说"这个问题我本地已经处理过，可能是现场网络/环境问题"，然后切换到下一个演示功能。强推的优化点是：把演示脚本提前写下来，包含登录、发布职位、投递简历、查看状态、管理员审核、数据统计的完整链路，按脚本演，基本不会卡壳。
8. 从毕设到真实项目：一些延伸建议
这个系统做完之后，我发现它的代码结构可以很方便扩展出很多真实场景下的功能。比如数据库表加一张message表，配合 WebSocket 就能做成站内信通知；职位表加一个view_count字段，就能实现职位的浏览量统计；把学生端和企业端的列表改成 ElasticSearch 搜索，就能解决关键词查询的性能问题。
如果你打算把这个项目当作能力展示放进简历里，我建议你重点打磨三块：一是把权限模型搞清楚，最好画一张角色权限矩阵图，面试官问起来能讲清楚；二是把接口文档整理成一份完整的说明文档，这本身就是规范化开发的体现；三是了解一些基本的部署知识，比如怎么把前后端分别部署到一台云服务器上，用 Nginx 做反向代理。这些在简历上都能成为实打实的加分项。
我在实际做这个项目的过程中，最大的体会是：毕设项目的价值不在用了多新多炫的技术，而在于你能不能在限定的时间内，把一个业务完整地闭环实现掉。遇到问题知道怎么查、怎么试、怎么改，这个能力比什么都值钱。
如果你打算基于这个项目来改造，建议第一步先跑起来，按照 SQL 脚本导入数据、改配置、启动后端、启动前端、登录测试账号走一遍流程，把工程跑通了再谈定制，比一上来就改代码要稳妥得多。
