SpringBoot+Vue毕设：大学生就业招聘系统全栈开发实战

毕业设计选题年年被问，年年都有人纠结：技术栈限定死、时间有限，又要能答辩讲明白，还得能拿去找工作当谈资。我做过不少类似的 Java 全栈项目，也辅导过一圈准备毕设和课设的同学。说句实在话，SpringBoot+Vue 大学生就业招聘系统管理平台这个选题，是少数性价比极高的那一种——角色清晰、业务闭环完整、每一块拆出来都能讲，串起来又是一个真实场景。这篇文章把我从零搭建这套系统时走过的路、填过的坑、到最后答辩和面试都用得上的细节，从头到尾说一遍，正在做毕设、课设，或者想拿 Java 全栈项目当敲门砖的读者，可以照着我这条线去复刻。

1. 项目选题与模块规划：别一上来就幻想“全平台”

1.1 这个系统到底解决了什么问题

大学生就业招聘这个场景，信息分散是最大的痛点。学校的就业网、企业的官网、各种招聘群聊，信息满天飞但学生不知道怎么投，企业也不知道怎么筛。要做成系统，核心价值就是两条：把职位信息集中起来，把“投递-处理-反馈”的全流程管起来。

所以我建议你在开题报告里描述项目时，不要只写“开发一个招聘网站”，而是写“构建一个面向高校学生的就业信息整合与双向流转平台”——学生能查看企业发布的职位、投递简历、跟踪进度；企业能发布职位、筛选简历、发送面试邀请；管理员能审核入驻企业、治理用户内容、查看全局统计。这句话会贯穿整个项目的架构设计，后面所有表结构和页面都是围绕它展开的。

1.2 三种角色的业务边界

常见的毕设/课设版招聘平台，我建议只做三个角色，别再加什么高校辅导员角色了。角色一多，数据库关系和权限判断会成倍变复杂。

这三个角色之间不是平行孤立的，是一个纵向闭环：企业发布职位 → 学生浏览投递 → 企业筛选邀请 → 学生确认结果。答辩时把这条链路讲清楚，评委就很难继续追问“系统业务逻辑是否完整”这种问题。

1.3 需求规划阶段最容易犯的错：什么功能都想要

我每年都会碰到一两个同学，一上来就要做“招聘+聊天+在线笔试+推荐算法”，做完开题计划一看，工作量够硕士毕业了。这里说一个比较扎心的经验：毕设系统赢在闭环，输在发散。你在短短几个月的课设/毕设周期里，把核心主流程做到“能用、正确、稳定”，远胜于一堆酷炫但没做完的边角功能。

当时我给自己定的规划原则是：

• 核心主线（职位发布→投递→筛选→面试邀请）必须完整，这是项目的生存线；
• 辅助线（通知消息、简历上传、数据统计）可以在主线完成后追加；
• 完全不做（聊天、在线笔试、推荐算法）之类的大模块，只作为答辩时“未来展望”一句话带过。

这个取舍很重要。你后面要写代码、写文档、准备答辩PPT，时间根本经不起浪费，先把主路径走通，再谈别的东西。

2. 数据库设计：招聘平台表结构应该这样拆

后端代码写得好不好，很大程度取决于建表时把关系理得清不清楚。我建表的原则是：每一张表都能回答一个具体的业务问题，表太多说明你没想清楚，表太少说明数据会冗余成一锅粥。

2.1 用户与权限模型别过度设计

很多教材一讲权限就端出 RBAC 的五个表：用户表、角色表、权限表、用户角色关联表、角色权限关联表。但说实话，招聘平台这个场景下，用户的权限粒度根本不需要拆到“按钮级”，做成三张表即可：

-- 用户主表：三个角色共用一张表，用 role 字段区分 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录账号', password VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', role TINYINT NOT NULL COMMENT '1学生 2企业 3管理员', status TINYINT DEFAULT 1 COMMENT '1正常 0禁用', create_time DATETIME, update_time DATETIME ); -- 学生扩展信息表 CREATE TABLE student_profile ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT '关联sys_user.id', real_name VARCHAR(50), gender TINYINT, school VARCHAR(100), major VARCHAR(100), degree VARCHAR(20), phone VARCHAR(20), email VARCHAR(100), skill_tags VARCHAR(500) COMMENT '逗号分隔的技能标签' ); -- 企业扩展信息表 CREATE TABLE company_profile ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, company_name VARCHAR(100) NOT NULL, industry VARCHAR(50), scale VARCHAR(30), address VARCHAR(200), description TEXT, auth_status TINYINT DEFAULT 0 COMMENT '0未审核 1通过 2拒绝' );

这套设计的好处是，用户的公共属性（账号、密码、状态）集中管理，业务属性（学生、公司）拆出去扩展，后续想加字段不用动主表。登录时根据role去不同的扩展表取信息，逻辑很清晰。

2.2 核心业务表：职位、简历、投递关系是关键

围绕招聘主流程，核心就三张表：职位表、简历表、投递记录表。投递记录表是最容易被忽视的——很多新手学生喜欢把“我投了哪些职位”存成一个拆不开的字段，比如在用户表里加一个applied_job_ids的逗号拼接字段，这是大忌。

-- 职位表 CREATE TABLE job ( id BIGINT PRIMARY KEY AUTO_INCREMENT, company_id BIGINT NOT NULL COMMENT '发布企业', title VARCHAR(100) NOT NULL, category VARCHAR(50) COMMENT '职位类别', city VARCHAR(50), salary_min INT COMMENT '薪资下限(千/月)', salary_max INT, job_desc TEXT, requirement TEXT, status TINYINT DEFAULT 0 COMMENT '0草稿 1已发布 2已下架', create_time DATETIME, update_time DATETIME ); -- 简历表 CREATE TABLE resume ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT '学生用户', title VARCHAR(100) DEFAULT '我的简历', file_url VARCHAR(255) COMMENT '上传的PDF简历路径', content TEXT COMMENT '在线简历内容(JSON文本)', is_default TINYINT DEFAULT 0 COMMENT '1为默认投递简历', create_time DATETIME, update_time DATETIME ); -- 投递记录表：核心关联表 CREATE TABLE job_application ( id BIGINT PRIMARY KEY AUTO_INCREMENT, job_id BIGINT NOT NULL, student_id BIGINT NOT NULL COMMENT '投递的学生用户id', resume_id BIGINT, status TINYINT DEFAULT 0 COMMENT '0已投递 1企业已查看 2已邀面试 3已通过 4已淘汰', enterprise_note VARCHAR(500) COMMENT '企业备注，仅企业内部可见', apply_time DATETIME, update_time DATETIME, UNIQUE KEY uk_job_student (job_id, student_id) COMMENT '防止重复投递' );

那个唯一索引uk_job_student是我特别建议加的一行。学生手滑连点两次投递按钮，如果业务层忘写重复判断，至少数据库这一层能兜住，不会产生两条脏数据。这套表结构已经能跑通绝大多数毕业设计需要的前后台功能了。

2.3 建表时的几个实用约定

踩过 MySQL 的坑之后，我基本养成了三个习惯：

第一，字符集统一用utf8mb4。之前有同学用utf8，结果往简历的description字段里存 emoji 字符直接报错，面试官填了个“技术栈：Java▫”“表情符号”就把接口打崩了，换utf8mb4才解决。

第二，时间字段直接用datetime，别用int存时间戳，也别用timestamp。timestamp有一个 2038 年问题——数据量小无所谓，但答辩时被老师提到这种细节很影响观感，用datetime更省心。

第三，逻辑删除字段delete_flag能加就加。招聘业务的职位下架不等于数据删除，学生的投递记录也应该能追溯。我会在每个核心表上挂一个delete_flag TINYINT DEFAULT 0，查询 SQL 统一带where delete_flag = 0，对后续做数据分析报表也友好。

3. SpringBoot 后端工程：分层、认证和版本坑

3.1 Maven 项目结构和核心依赖

我的后端代码一般按照开发中常见的标准分层组织，模块之间各司其职，答辩也容易讲清楚：

edu-recruit/ ├── pom.xml └── src/main/java/com/example/recruit ├── RecruitApplication.java ├── config/ // 跨域、拦截器、自定义配置 ├── controller/ // 接口层，只做参数接收和返回 ├── service/ // 业务逻辑层，核心事务都在这 ├── mapper/ // MyBatis-Plus 的 Mapper 接口 ├── entity/ // 数据库实体类 ├── common/ // 统一返回体、异常处理 └── util/ // JWT、加密等工具类

pom.xml 里的核心依赖没什么争议，但版本要特别注意。我见过最多的坑就是springboot 版本太高 + mybatis-plus 版本不匹配，启动时直接报NoSuchMethodError，错得毫无头绪。如果你跟着当前主流教程学，建议直接锁定：

• SpringBoot 2.7.18（别用 3.x，除非你确定整套教程都适配）
• MyBatis-Plus 3.5.5（带mybatis-plus-boot-starter）
• MySQL 驱动mysql-connector-j8.0.33
• JWT 可以用jjwt-api/impl/jackson0.11.5

另外强烈推荐引入hutool-all工具包。有些同学写代码还在手写 BeanUtils、日期工具，没必要，用 hutool 能省大量时间，而且项目看起来更成熟。

3.2 登录认证：JWT 怎么做，才不会被老师在答辩时问倒

招聘平台的接口不能裸奔，区分用户身份是刚需。我对比过 Session 和 JWT 两种方案，毕设场景 JWT 更占优势：无状态、前后端分离 App 端也能用、代码里实现拦截器讲起来很直观。

登录接口核心逻辑：

@RestController @RequestMapping("/api/auth") public class AuthController { @Autowired private IUserService userService; @PostMapping("/login") public Result<UserVO> login(@RequestBody LoginDTO dto) { // 1. 查用户，检查账号状态 SysUser user = userService.getOne( new LambdaQueryWrapper<SysUser>() .eq(SysUser::getUsername, dto.getUsername())); if (user == null) { throw new BizException("账号或密码错误"); } // 2. 密码校验(BCrypt) if (!BCrypt.matches(dto.getPassword(), user.getPassword())) { throw new BizException("账号或密码错误"); } if (user.getStatus() == 0) { throw new BizException("账号已被禁用"); } // 3. 签发 token String token = JwtUtil.createToken(user.getId(), user.getUsername(), user.getRole()); UserVO vo = new UserVO(); vo.setId(user.getId()); vo.setUsername(user.getUsername()); vo.setRole(user.getRole()); vo.setToken(token); return Result.success(vo); } }

密码必须用 BCrypt 加密，千万别明文存，可以不夸张地说，这是答辩老师第一眼就会翻的地方。这里有一点要提醒：BCrypt.matches 的校验对象是明文密码和数据库密文，不是两次密文比较。我有一次在帮学生调代码时发现他写成了“把后输入的密码再加密一次然后比较”，结果永远不可能相等，这种问题非常隐蔽。

拦截器是 JWT 方案的第二个核心。我在config/下注册了拦截器，所有/api/**请求先过一道 token 校验，再按角色放行：

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BizException(401, "未登录"); } return JwtUtil.verify(token.replace("Bearer ", "")); } }

注意拦截器里不要写具体业务，只做鉴权。接口层里通过@RequestHeader("Authorization")或 ThreadLocal 拿到当前用户 id 来处理业务数据，保证“只操作自己权限范围内的数据”。

3.3 统一返回和异常处理：代码质量分水岭

很多学生项目接口返回格式五花八门，有的直接返回实体、有的塞进 HashMap，前端拿到数据之后要一层一层猜字段。正确的做法是全项目统一返回体：

@Data public class Result<T> { private Integer code; // 200 成功，401 未登录，500 业务异常 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMessage("操作成功"); r.setData(data); return r; } }

同时写一个全局异常处理器。用@RestControllerAdvice捕业务异常和未知异常，返回结构一致的错误信息。这事看着不大，但它决定你前端 axios 拦截器是长成“统一弹错误提示”还是“每条报错各写各的”。

提示：全局异常处理器里，BizException要单独 catch 并保留业务提示，Exception兜底返回“系统繁忙”。否则你前端会收到一堆看不懂的英文堆栈。

4. Vue 前端工程：路由、状态拦截与跨域联调

4.1 脚手架初始化和目录规划

前端我用 Vue 3 + Vite + Element Plus，这套组合教程多、组件全，招聘平台的表格、表单、对话框直接抄组件就能用。初始化命令就一行，后面依赖会自动装：

npm create vite@latest edu-recruit-web -- --template vue

目录规划我遵循“按角色分模块，按功能分文件”的原则：

src/ ├── api/ // 按业务拆的请求模块 │ ├── auth.js │ ├── job.js │ ├── application.js ├── router/index.js // 路由表 ├── store/ // Pinia，存用户信息和 token ├── views/ │ ├── student/ // 学生端页面 │ ├── company/ // 企业端页面 │ ├── admin/ // 管理端页面 │ ├── login.vue │ └── register.vue ├── utils/request.js // axios 封装 └── App.vue

这样规划的好处是，答辩时候别人问你“这项目怎么文件夹这么多”，你可以理直气壮地说：我是按工程化思维组织的，页面和接口分层、业务和工具隔离。

4.2 路由守卫和角色控制

招聘平台前端有一个很实际的需求：学生登录后不能访问企业后台，企业账号不能打开管理统计页。这必须靠路由守卫在跳转前拦截，不能只靠“菜单不放那个入口”。

// router/index.js const routes = [ // 登录页省略 { path: '/company', component: Layout, meta: { roles: ['company'], requiresAuth: true }, children: [ { path: 'job-list', component: CompanyJobList }, { path: 'applications', component: ApplicationList } ] }, { path: '/admin', component: Layout, meta: { roles: ['admin'], requiresAuth: true }, children: [ { path: 'companies', component: AdminCompanyAudit }, { path: 'dashboard', component: AdminDashboard } ] } ]; router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.meta.requiresAuth) { if (!token) { next('/login'); return; } const role = localStorage.getItem('role'); if (to.meta.roles && !to.meta.roles.includes(role)) { next('/403'); return; } } next(); });

这里有个常见坑：本地存储里存 token、role，刷新后路由守卫读到的角色信息来自localStorage，但 Vue 实例里的状态是空的。所以刷新时要在App.vue的onMounted里重新读一次并写入 Pinia，或者干脆在router.beforeEach里直接读 localStorage，不要依赖只存在内存里的 Pinia 状态。

4.3 Axios 拦截器封装和跨域代理

axios 封装有两个硬指标：带上 token，并且统一拦 401。

// utils/request.js import axios from 'axios'; import { ElMessage } from 'element-plus'; const service = axios.create({ baseURL: '/api', timeout: 10000 }); service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { ElMessage.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } return res.data; }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); window.location.href = '/login'; } ElMessage.error('网络异常'); return Promise.reject(error); } );

开发环境的跨域问题也不用改后端加 CORS，用 Vite 的 proxy 配置，让前端发的/api请求都代理到后端的 8080：

// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } });

这样就实现了“前端感觉自己在请求同源地址，后端也不知道来的是跨域请求”，比在 SpringBoot 里手动写一堆 CORS 配置稳得多。

5. 核心业务实现：从投递到面试邀请的状态流转

5.1 职位发布与上下架逻辑

企业发布职位不是立即可见，这也是招聘平台的正常业务逻辑——职位创建后默认是草稿，企业确认无误后点击“发布”才变status=1；发布后可以主动下架。这块代码不复杂，但为什么要单独拿出来讲？因为这里有事务边界。发布职位会更新职位表状态，可能还要同时给管理员生成一条待审核记录，这两个操作必须在一个事务里。

@Service public class JobServiceImpl extends ServiceImpl<JobMapper, Job> implements IJobService { @Override @Transactional(rollbackFor = Exception.class) public Long publishJob(JobDTO dto, Long companyUserId) { Job job = new Job(); BeanUtil.copyProperties(dto, job); job.setCompanyId(companyUserId); job.setStatus(0); // 草稿 this.save(job); // 如果需要管理员审核，可以在此插入audit_log记录 return job.getId(); } @Override @Transactional(rollbackFor = Exception.class) public void closeJob(Long jobId, Long companyUserId) { Job job = this.getById(jobId); if (job == null || !job.getCompanyId().equals(companyUserId)) { throw new BizException("职位不存在或无权操作"); } job.setStatus(2); this.updateById(job); } }

事务注解记得加rollbackFor=Exception.class，这是标准习惯。不写这一行的话，运行时异常默认回滚没问题，但 Checked Exception 不会回滚，位置关系错了很可能会导致数据只改一半。

5.2 学生投递简历：防重复 + 状态反馈

投递接口是整系统最容易被追问的接口。业务上要注意三点：一是防重复投递，二是记录初始状态，三是给企业一个处理入口。

@Override @Transactional(rollbackFor = Exception.class) public void applyJob(Long jobId, Long studentId, Long resumeId) { // 1. 校验职位存在且已发布 Job job = jobMapper.selectById(jobId); if (job == null || job.getStatus() != 1) { throw new BizException("职位不可投递"); } // 2. 防重校验（业务层兜底） Long count = applicationMapper.selectCount( new LambdaQueryWrapper<JobApplication>() .eq(JobApplication::getJobId, jobId) .eq(JobApplication::getStudentId, studentId)); if (count > 0) { throw new BizException("您已经投递过该职位"); } // 3. 插入投递记录 JobApplication application = new JobApplication(); application.setJobId(jobId); application.setStudentId(studentId); application.setResumeId(resumeId); application.setStatus(0); application.setApplyTime(new Date()); applicationMapper.insert(application); }

这里我特意保留了业务层的 count 判断，哪怕表上已经有唯一索引，这也是良好习惯——数据库兜底 + 业务层给友好提示，两层防护都到位，答辩老师说并发问题的时候，你直接甩出这两层设计。

5.3 企业处理简历：筛选、邀请面试、结束流程

学生在“我的投递”里看状态，企业端也要有一个操作台。状态机流转可以用一个枚举管理：

核心操作接口我会设计成updateStatus(applicationId, targetStatus, operatorId)这样的统一方法，里面先校验操作者是不是该职位所属公司，再校验状态转换是否合法，比如“已淘汰”不能直接变“已邀面试”。状态机加越权校验，这两个话题答辩老师百问不厌。

5.4 站内通知：用最简单的方式实现“有反馈”

学生投递后希望被反馈，企业邀请面试后学生要能收到提醒。可选的方案有 websocket、消息队列，但毕设阶段最简单的做法是建一张消息表，业务关键动作时插入消息记录，前端在导航栏或消息中心定时轮询读取未读条数。

这张表和投递表一样属于“所有角色都在用”的基础表。结构很简单：id、from_user_id、to_user_id、content、type、is_read、create_time。别小看它，这个模块能撑起你“系统与人之间交互完整”的叙述。

6. 前后端部署与联调：Vue 打包进 SpringBoot 的那些坑

6.1 开发环境能跑，不代表部署环境能跑

很多同学本地联调一切正常，一动服务器就崩。我复盘过，出问题的点基本集中在三块：数据库连接配置、静态资源位置、跨域/路径问题。

先看数据库。本机用 Navicat 连接好好的，换成服务器上的 MySQL 就报各种错误，最常见的就是SSL connection error。这不是什么高深问题，多半是 Java 连接串里缺少参数：

spring: datasource: url: jdbc:mysql://你的服务器IP:3306/edu_recruit?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: xxxx

useSSL=false是给老版本 MySQL 用的，真正重要的是characterEncoding=utf8和serverTimezone=Asia/Shanghai。前者防乱码，后者防你系统里 “2024-XX-XX” 日期字段跟数据库差了 8 小时。还有一个隐蔽坑：如果你用的是 MySQL 8+，驱动类名是com.mysql.cj.jdbc.Driver，别写成老的com.mysql.jdbc.Driver，否则连接时直接报 ClassNotFoundException。

6.2 部署方案：把 dist 扔进 SpringBoot 的 static 目录

毕设项目一般没有独立服务器预算，最轻量的做法是Vue 打包成静态文件后，直接塞进 SpringBoot 的src/main/resources/static目录，一起打成 jar。这样后端一个端口全搞定，不用配 Nginx，部署运维成本几乎为零。

步骤也就三步：

# 1. 前端构建 npm run build # 构建后会在项目根目录生成 dist/ 文件夹 # 2. 将 dist 目录里的内容全部复制到 # SpringBoot 项目的 src/main/resources/static/ 下 # 3. 重新打包后端 mvn clean package -DskipTests java -jar edu-recruit.jar

这里有个极容易踩的坑：Vue 的路由使用 history 模式时，页面刷新会 404。因为 SpringBoot 没有对应的 controller 路径来处理/student/applications这种前端路由，刷新时后端会去找这个 URL 的映射，找不到就报 404。

解决办法有两条路子：

1. Vue 路由改用createWebHashHistory()（hash 模式），URL 变成/#/student/applications，刷新不会 404，毕设完全够用；
2. 保持 history 模式，然后在 SpringBoot 加一个 Fallback Controller，把所有不带/api前缀的请求转发到 index.html。工作量不大，但需要额外写类和配置，看你想不想讲这点。

我建议毕设选第一条，省时间。如果你以后想上生产环境再用 Nginx 处理 history 路由转发，那时再切 history 模式也不迟。

6.3 外部 Tomcat 部署与文件上传路径

如果学校要求必须打成 war 包丢进 Tomcat，那你 pom 里要加<packaging>war</packaging>，并排除 SpringBoot 内嵌的 Tomcat：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency>

同时主类要继承SpringBootServletInitializer，不然打出的 war 包启动不了。这个细节坑得好几个同学在部署当天怀疑人生。

文件上传方面，学生上传 PDF 简历如果存本地磁盘，开发环境和服务器环境的路径不一致非常容易出错。做漂亮点可以接 MinIO，配一个application.yml里的自定义存储路径并用相对路径拼到配置里。没时间的话，先存本地磁盘，但一定要把上传目录配置化。

7. 答辩和面试：让项目的价值被看见

7.1 项目亮点怎么说才不空洞

到答辩环节，很多同学只会说“我用了 SpringBoot 和 Vue”。评委听完毫无感觉。“技术栈”和“项目亮点”是两码事。我建议从三个加分点准备话术：

第一，权限体系的完整性。你不是只做了登录页，而是做了 JWT + 拦截器 + 前端路由守卫 + 接口层越权校验，四层一起兜底。这直接证明你理解“系统安全”不是某一行代码，而是一个体系。

第二，状态机的规范化设计。职位有草稿/已发布/已下架状态，投递有已投递/已邀约/已通过/已淘汰状态。用一个枚举类管理这些状态，不允许非法流转。这说明你有工程意识，不是想到哪写到哪。

第三，统一异常和分层设计。全局异常处理器、统一返回体、Controller/Service/Mapper 三层分离、事务回滚，这些都是把“学习项目”和“工程项目”区分开的细节。

7.2 面试官最常追问的问题清单

我把辅导过程中被问得最多的问题列在这里，建议每一个都做一次“模拟回答”：

• 项目是怎么分层的？为什么 Controller 里不写业务代码？
• JWT 登录流程是什么？token 过期了怎么处理？刷新怎么办？
• 学生重复投递你怎么防的？如果两个请求同时打到后端呢？
• 分页是怎么实现的？数据量大了怎么优化查询？
• 简历上传之后存在哪？文件名怎么处理？路径怎么访问？
• 前后端怎么联调的？CORS 和 proxy 有什么区别？
• 多个人同时操作同一个职位会不会数据错乱？

这些不是刁难，都是毕设项目里真正会遇到的细节。能答上来的，面试官基本就会往下一个层级聊了。

7.3 从毕设到简历项目的三步增强

如果你不满足于“能毕业”，想把项目写进简历，我的建议是在毕业设计主线完成后按顺序做三步增强：

• 第一步：加入 Redis。把职位列表缓存到 Redis，减少数据库访问，同时聊聊缓存一致性问题。这一句话就能把项目从“有功能”拉到“懂性能”。
• 第二步：接入可视化统计。用 ECharts 做管理员的招聘数据大屏，展示职位投递趋势、各专业投递热度，给系统加一个“数据说话”的维度。
• 第三步：文件存储接 MinIO。把简历 PDF 和图片从本地磁盘挪到对象存储，写一个简单的 MinIO 上传工具类。这一条实现不难，但很显专业度。

最后的最后说句实在话：这类毕设系统源码网上能搜到一堆，但你拿到的别人的代码，答辩时老师提问很容易露馅。我给的这套设计思路和代码结构，全部是从“能自己完整讲一遍”的标准出发的，你只要按章节顺序把代码自己敲一遍、把状态流转跑通一遍，答辩半小时基本稳了。我自己带过的同学里，凡是按这个路径踏实做完的，面试讲项目时也都明显比别人有底气。