每年到毕业季，总有一批计算机专业的学生要面对同一个课题：网上求职招聘系统。说实话，这个题目在毕业设计里属于“经典永流传”的类型，每年都有人做，但每年能做出彩的并不多。原因往往不是技术选型有多难，而是很多人把Spring Boot当成了“配置启动器”，业务逻辑一塌糊涂，写出来的系统就是一套CRUD堆叠，答辩时被问几个场景问题就卡壳了。
如果你也正在做或者打算做这个课题，这篇文可以帮你把整个系统的骨架、关键实现和避坑点都理顺。我会从业务拆解、表结构设计、核心接口实现、常见坑位几个方向展开，代码基于Spring Boot 2.7 + MyBatis-Plus + MySQL + Redis，前端技术栈不强制，你可以用Vue，也可以用Thymeleaf，核心逻辑都在后端。这套方案也在实际带毕设的过程中反复调过，跑通没问题，答辩也够用。
1. 项目概述与核心需求拆解
1.1 求职招聘系统的业务场景
网上求职招聘系统听起来就是一个多角色平台，但“多角色”这三个字在设计上很容易翻车。很多同学一开始就把用户表设计成一张大表，搞一个role字段区分学生/求职者和企业HR，然后所有业务逻辑都堆在同一个Service里，后期维护成本特别高，扩展也难。
实际业务场景里，系统至少要有三类角色：
- 求职者：注册登录、完善简历、浏览职位、投递简历、查看投递反馈。
- 企业端（HR/管理员）：注册企业账号、发布职位、管理职位（上下架）、查看收到的简历、更新投递状态（筛选/面试/录用/拒绝）。
- 平台管理员：审核企业账号和企业发布的职位，处理违规内容，统计平台数据。
从毕设角度，做到这三类角色就已经把系统撑起来了。如果你想把工作量做得更饱满，还可以加一个“管理员审核企业”的流程，企业注册后不是马上能发布职位，而是先提交审核，管理员通过后才有权限。这个流程虽然只多了一个字段和一个小接口，但能在答辩时讲出“业务闭环”，比单纯CRUD有分量得多。
1.2 为什么选Spring Boot作为核心框架
这个题目如果放在十年前，很多人会用SSH（Struts+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis）来写，配置一堆XML，光搭环境就得一整天。现在选Spring Boot，核心理由其实就三个字：省事儿。
Spring Boot把自动配置、内嵌Tomcat、Starter依赖管理这些都做好了，你不需要再自己配web.xml、配DispatcherServlet、配数据库连接池，一个spring-boot-starter-web就能跑起一个Web应用。对于毕业设计这种“需要在有限时间内交付一个完整系统”的场景，时间成本是最重要的。Spring Boot还能轻松集成Spring Security或Sa-Token做权限控制，用AOP做日志，用Redis做缓存，这些都是答辩时的加分点。
另外，Spring Boot的学习曲线对新手相对友好。网上资料极多，遇到问题几乎都能搜到解决方案。你后期维护和改bug的成本会低很多，不至于卡在一个环境问题上两天。
2. 系统设计与技术选型
2.1 整体架构与角色权限设计
我习惯把系统拆成两个端：用户端和管理端。用户端面向求职者（web端/移动端浏览器）和企业HR；管理端面向平台管理员。技术上前后端分离，前端用Vue + Element UI，后端提供RESTful API，通过JWT（JSON Web Token）做身份认证。
权限模型采用RBAC（基于角色的访问控制）简化版。不搞user-role-permission三张表那么重，只需要在用户表里加一个role字段，然后在后端写一个拦截器或者用Spring AOP注解决定接口是否能访问。
如果觉得自定义注解麻烦，也可以直接用Sa-Token。它比Spring Security上手简单很多，本身提供了StpUtil.login()、@SaCheckLogin、@SaCheckRole("admin")这些能力，非常适合毕设场景。我下面的示例用自定义JWT + interceptor的方式，代码量不大，也便于讲解原理。
核心角色字段：
| 角色 | 编码 | 说明 |
|---|---|---|
| 求职者 | seeker | 浏览职位、管理简历、投递 |
| 企业HR | company | 发布职位、处理投递 |
| 平台管理员 | admin | 审核企业、管理职位 |
2.2 核心技术栈清单
这是我在实操中用的组合，你可以类比替换：
| 层次 | 技术/框架 | 作用 |
|---|---|---|
| 后端框架 | Spring Boot 2.7.x | 项目基础 |
| 持久层 | MyBatis-Plus 3.5.x | 简化SQL开发 |
| 数据库 | MySQL 8.0 | 数据存储 |
| 缓存 | Redis 5.0+ | Token、热门职位缓存 |
| 认证 | JWT + 拦截器 | 登录态与权限控制 |
| 接口文档 | Knife4j 3.0.3 | 生成Swagger文档 |
| 前端 | Vue 2 + Element UI | 后台管理页面 |
| 构建工具 | Maven 3.6+ | 依赖管理 |
这里有两个容易踩的坑。第一个是Spring Boot 2.6之后的版本，默认的路径匹配策略从AntPathMatcher变成了PathPatternParser，如果集成Springfox（Swagger）3.x，会报springfox.documentation.spring.web.WebMvcPatternsRequestConditionWrapper之类的错。最简单的解法是改配置：spring.mvc.pathmatch.matching-strategy=ant_path_matcher。第二个是MyBatis-Plus和Spring Boot版本之间的兼容问题，建议直接用3.5.1以上版本，避免出现Mapper扫描不到的情况。
3. 数据库设计与核心表结构
3.1 用户与角色模型
数据库设计直接决定你后期写接口时顺不顺畅。我建议先画一张粗粒度的ER图，再建表。用户中心的核心表就一张：sys_user。后续扩展出的candidate_profile（求职者信息表）和company_profile（企业信息表）用user_id关联用户表，做到“通用账号体系 + 扩展信息”。
sys_user表设计参考：
CREATE TABLE `sys_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录用户名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `role` varchar(20) NOT NULL COMMENT '角色：seeker/company/admin', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：1正常 0禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';注意密码一定要加密。我见过很多毕设直接用明文密码，答辩老师一问“密码安全怎么解决”就尴尬。推荐用Spring Security里的BCryptPasswordEncoder，它能自动加盐，同一个密码每次加密结果都不同，安全性有保证。
3.2 职位、简历、投递关系设计
职位表和简历表是核心业务表。职位表设计要点：
company_id关联企业账号用户ID，用来区分是谁发布的。title、category、salary_min、salary_max、city、experience_required、education_requirement这些字段用于列表筛选和职位详情展示。status字段管理职位上下架，比如0-待审核、1-招聘中、2-已下架、3-审核拒绝。
简历表设计要点：
user_id关联求职者账户。real_name、gender、birthday、phone、email等基础信息。education_experience、work_experience、project_experience建议用JSON或TEXT类型存储，因为每个人的经历条数不固定。如果非要做规范化，也可以拆成子表，但毕设的复杂度不建议搞太高，TEXT存储已经够用，查询的时候再单独解析。
投递关系表是整个系统的业务桥梁：
CREATE TABLE `job_delivery` ( `id` bigint NOT NULL AUTO_INCREMENT, `job_id` bigint NOT NULL COMMENT '职位ID', `resume_id` bigint NOT NULL COMMENT '简历ID', `seeker_id` bigint NOT NULL COMMENT '求职者用户ID', `company_id` bigint NOT NULL COMMENT '企业用户ID', `status` tinyint NOT NULL DEFAULT '0' COMMENT '状态：0待处理 1已查看 2面试 3录用 4不合适', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='职位投递表';投递表加上seeker_id和company_id，是为了避免在业务查询时频繁关联用户表，空间换时间，查询效率高很多。
4. 关键模块实现与实操要点
4.1 JWT登录与权限控制
登录接口的流程不复杂，但细节很多。第一步校验验证码（如果做了），第二步校验用户名密码，第三步生成Token返回给前端。前端后续请求在Header里带Authorization: Bearer <token>，后端拦截器解析Token，拿到用户信息。
推荐用jjwt库，版本用0.9.1，因为API经典稳定。生成Token的核心代码：
public String createToken(User user) { // 过期时间：2小时 long expire = 3600 * 1000 * 2; return Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim("role", user.getRole()) .claim("username", user.getUsername()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + expire)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }拦截器里要注意：放行登录、注册、验证码等接口，其余接口校验Token；同时根据接口上的角色注解判断当前用户是否有权限访问。拦截器实现HandlerInterceptor接口，在preHandle方法里写完逻辑就行。
我踩过的一个坑是Token签名密钥写死在代码里，答辩时被问“密钥泄露怎么办”。后来我改成从application.yml里读取，再后来又加了一步：把密钥放到环境变量里。其实毕设做到从配置文件读取就够用了，但你要能说出为什么不能硬编码。
4.2 职位发布与检索实现
职位发布接口相对简单，但要做好字段校验。比如薪资区间必须salary_max >= salary_min，否则会出现工资越往下越高的笑话。发布时如果开启了管理员审核流程，status设置成0，否则直接1。
职位检索是业务重点。一个实用的检索接口至少支持以下参数：关键词、城市、职位类别、经验要求、学历要求、薪资范围、排序方式。用MyBatis-Plus的LambdaQueryWrapper可以快速拼条件：
LambdaQueryWrapper<Job> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(keyword), Job::getTitle, keyword) .eq(StringUtils.hasText(city), Job::getCity, city) .eq(categoryId != null, Job::getCategoryId, categoryId) .eq(experienceRequired != null, Job::getExperienceRequired, experienceRequired) .ge(salaryMin != null, Job::getSalaryMax, salaryMin) // 最低薪资不低于期望 .le(salaryMax != null, Job::getSalaryMin, salaryMax) // 最高薪资不高于期望 .eq(Job::getStatus, 1) .orderByDesc(Job::getCreateTime);这里有个细节：薪资检索如果直接用salary_min >= 用户输入的min，会把很多“8k-10k”的职位在用户搜12k时也筛出来，因为12k大于8k，但12k也大于10k，不符合预期。更好的策略是取两个字段做区间重叠判断：职位薪资区间与用户期望区间有交集就认为是匹配的。上述代码就是用的重叠逻辑，可以参考。
职位详情页会有浏览量统计，建议用Redis的increment做自增，然后异步或定时把数据同步回MySQL，避免每次查询都直接操作数据库。
4.3 简历投递与状态流转
投递接口要做防重复提交。同一用户对同一职位只能投递一次，这一点在数据库层面可以通过UNIQUE KEY uk_job_resume (job_id, resume_id)约束来兜底，在代码层面用Redis分布式锁防止并发下突破唯一约束。毕设不一定需要分布式锁，但至少要有重复投递校验：
Long count = deliveryMapper.selectCount( new LambdaQueryWrapper<JobDelivery>() .eq(JobDelivery::getJobId, jobId) .eq(JobDelivery::getSeekerId, currentUserId) ); if (count > 0) { throw new BizException("你已投递过该职位，请勿重复投递"); }投递状态流转建议做成状态机。虽然表面上看只是改一个status字段，但如果没有状态校验，用户就可能从“已投递”直接改成“已录用”，或者企业端把状态改回“待处理”，出现逻辑混乱。最简单的状态机写法就是在Service层写一个transition方法：
Map<Integer, List<Integer>> transitions = new HashMap<>(); transitions.put(0, Arrays.asList(1)); // 待处理 -> 已查看 transitions.put(1, Arrays.asList(2, 4)); // 已查看 -> 面试/不合适 transitions.put(2, Arrays.asList(3, 4)); // 面试 -> 录用/不合适每次更新前先校验当前状态和目标状态是否在合法转换关系里，不合法就抛异常。这一小段逻辑在答辩时非常能体现你的工程思维。
4.4 后台管理模块的审核与统计
后台管理模块通常是毕设里最容易被忽略的部分，很多人只做一张列表展示就不管了。其实管理员端要做的事很多：企业审核、职位审核、用户禁用/启用、数据统计。
企业审核这里有个业务设计细节：企业账号注册后，可以登录系统，但如果没有通过审核，发布职位接口就要被拦截。我是在JobServiceImpl里先查企业状态，再决定是否允许发布：
CompanyProfile company = companyProfileMapper.selectById(userId); if (company == null || !Integer.valueOf(1).equals(company.getAuditStatus())) { throw new BizException("企业信息未通过审核，暂时无法发布职位"); }数据统计可以用一个简单的折线图接口，返回最近7天每天的职位发布量、投递量、注册量。用SQL的GROUP BY DATE(create_time)就能搞定，不必引入复杂的数据分析框架。统计接口要注意时区问题，MySQL和Java默认时区不一致会导致天数差8小时，可以在连接串上加上serverTimezone=Asia/Shanghai。
5. 常见问题与排查技巧
5.1 启动时报循环依赖或者Mapper找不到
循环依赖在Spring Boot 2.6默认不允许，但很多同学写代码时Service之间互相调用，一启动就报The dependencies of some of the beans in the application context form a cycle。解决思路是重构，把公共逻辑抽到独立的Service里，或者用@Lazy临时解决。不过毕设答辩时建议说“通过拆分职责消除了循环依赖”，这才是正向答案。
Mapper找不到通常是忘了加@MapperScan，或者Mapper接口没有加@Mapper注解。MyBatis-Plus在application.yml里配置mapper-locations: classpath*:mapper/**/*.xml后，也要确保XML文件的路径和Namespace对应正确。
5.2 懒加载导致JSON序列化异常
如果你用了MyBatis-Plus或者JPA的懒加载，在返回JSON时可能会遇到could not initialize proxy - no Session。这个问题在我带过的学生中出现频率很高。解决方案是：
- 在实体类中，把需要返回给前端的关联对象直接用查询接口封装成VO，不要直接返回Entity。
- 或者关闭懒加载，使用即时加载。
我建议用第一种方案。写一个JobVO，包含职位信息、公司名称、公司Logo、所属行业，然后通过BeanUtils.copyProperties拷贝，再手动填充额外字段。这样既能避免序列化问题，又能控制接口返回字段，不会把内部字段暴露出去。
5.3 跨域导致前端无法访问接口
前后端分离后，跨域是必然要处理的。如果你用Vue在8080端口，后端在8081端口，浏览器会拦截跨域请求。在Spring Boot里写一个配置类：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }注意allowCredentials(true)时，allowedOrigins不能写成*，要用allowedOriginPatterns，否则前端请求带Cookie时会报错。
5.4 打包部署时的常见坑
本地能跑，打包部署后一堆问题，这是毕设里最常见的“最后一公里”问题。首先确认pom.xml里有没有打包插件，Spring Boot项目至少要有spring-boot-maven-plugin，否则打出来的jar不能直接运行。其次，application.yml里的数据库连接、Redis地址要改成服务器或自己的公网IP，不能用localhost。
另外，如果用了外部静态资源上传（比如简历照片、企业Logo），本地路径和服务器路径要配置成相对路径或者对象存储路径。不要直接写死D:/upload/，换个环境就崩。我习惯在配置里增加一个file.upload-dir字段，然后通过@ConfigurationProperties读取。
6. 答辩高频问题与功能扩展建议
6.1 评委最喜欢问的几个问题
做毕设答辩时，评委大概率会问这几个方向的问题，提前准备比临场编要强得多：
- “为什么选择Spring Boot？”回答核心思想：自动配置减少开发成本、生态丰富、内嵌容器易于部署，适合快速迭代的小型系统。
- “如果用户量大了，你觉得系统瓶颈在哪里，怎么优化？”可以从数据库索引、Redis缓存、异步消息队列、静态资源CDN几个方向来答。
- “怎么保证数据安全？”谈密码加密、接口鉴权、SQL注入防护（MyBatis-Plus的
#{}预编译）、XSS过滤。 - “投递状态是怎么流转的？”状态机这套设计讲清楚就很加分。
6.2 后续可以怎么扩展
如果你想让这个毕设更有深度，可以在现有基础上做几个扩展：
- 引入Elasticsearch做职位全文检索，替代MySQL的
LIKE模糊查询，同时讲一讲倒排索引的原理。 - 引入RabbitMQ做投递消息通知，当用户投递成功后，异步把站内信和邮件通知发给HR。
- 增加“为你推荐”功能，基于用户浏览历史、投递偏好做简单的协同过滤推荐，不需要太复杂，用基于用户标签的算法就能实现。
技术不在于多，而在于你能不能把每一步为什么这么做讲清楚。能把上面任何一个扩展做出来并说出原理，答辩通过基本没有压力。
最后分享一个我在带项目时的习惯：写完每个接口之后，不要急着做下一个功能，先自己用Postman过一遍边界条件，比如不传参数、传错格式、未登录请求等。很多问题看着小，但会在答辩演示时让你当场社死。这个习惯比任何框架知识都值钱。等你把整套系统的代码过完一遍，再来回头看招聘网站的细节，就会明白，所谓的“网上求职招聘系统”不是简单的信息展示，而是一套围绕“匹配”和“流转”的业务逻辑实现。你把这两个核心点吃透了，这个毕设就真的坐实了。
