这个题目说实话几乎每年计算机专业毕业设计名单上都会出现。你若是在搜索引擎里敲一下“springboot 毕业生招聘平台”能翻出几百篇大同小异的论文和源码。但正因为太常见才更需要想清楚为什么是SpringBoot你要做的到底只是一个数据库增删改查的“管理系统”还是一个真的能跑通求职与面试流程的“线上平台”我当初做这个选题时一开始也走偏了以为是写个CRUD换换皮就行直到把业务链路理清楚、把技术选型的为什么弄明白才发觉这题目背后的深浅。本文不打算给你贴一份完整的、动辄上千行的源码而是想跟你完整复盘一遍从选题、拆解需求、技术栈选型到核心模块的实现思路、常见的坑再到部署上线的完整链路。无论你是准备拿它当毕设还是想做一个真正能用起来的求职平台这篇内容应该能让你少走很多弯路。1. 毕业设计选题的“老牌项目”为什么还有深挖价值1.1 招聘平台的真实业务需求远不止“增删改查”“毕业生线上招聘平台”这个题目光看名字很容易被理解成“学生信息管理系统”加“职位信息管理模块”。如果你答辩时也这么讲评委大概率只会给你一个及格分。因为但凡有点经验的评委都会追问一句“你的平台和普通的招聘网站相比解决的核心问题是什么”高校毕业生的招聘业务链路其实很清晰学生要能浏览职位、投递简历、查看面试通知企业端要能发布职位、筛选简历、发起面试后台还要能做数据统计和内容审核。而线上招聘平台的核心逻辑是“匹配”——把合适的毕业生推给合适的企业反过来说把合适的企业带到学生面前。这就引出了几个纯粹的管理系统里不会重点考虑的问题简历投递的状态机要如何设计从“已投递”到“被查看”到“邀约面试”到“通过/不通过”每个状态之间的流转规则是什么职位筛选和推荐要不要做如果只有一页一页地翻列表那不叫“云聘”叫“信息黄页”。面试通知怎么触达站内信、邮件提醒、定时任务轮询哪个才是毕设阶段最合适的方案学生端的“身份认证”和企业端的“组织认证”如何区分权限模型怎么设计才不混乱这些需求是你在动手写代码之前就必须想明白的。不然代码写到一半你会发现数据表之间的关系根本撑不起业务逻辑回头的代价极高。1.2 为什么选SpringBoot而不是SSH或者Servlet原生开发这个问题几乎每个答辩老师都会问而且它比“你用了哪些技术”更能反映你对项目的整体认知。我的建议是不要只说“SpringBoot很流行”而要能讲清楚它到底解决了什么。早期JavaWeb开发典型技术栈是SSHStruts2 Spring Hibernate或者SSMSpringMVC Spring MyBatis它们本身并没有消失但配置的复杂度是真实的痛点XML配置文件动辄上百行各种Bean之间的依赖关系要靠手工维护部署的时候还要选Tomcat版本、调试Classpath。SpringBoot的核心思路是“约定优于配置”通过自动装配机制把一大批常用的配置在启动时自动完成。你在spring.factories或者AutoConfiguration.imports里声明自动配置类SpringBoot就会按照条件注解ConditionalOnClass、ConditionalOnMissingBean等判断是否生效。这意味着什么意味着你写简历模块的时候不需要关心数据源到底是怎么初始化的也不需要为了“JSON序列化日期格式不对”去翻几个小时的配置文件。你只需要专注于写自己的业务代码。对毕设阶段那种“一个月写完核心功能”的时间要求来说这是最合适的选择。当然SpringBoot本身也面临“全家桶”过重的问题这也是为什么后来Spring Cloud、SpringBoot直接整合各种组件能成为一种常态。它不是一个“轻量框架”它是一个“高度封装的一站式开发基座”。答辩时你要能说出来你选它的原因是它能让你在有限时间内把业务的复杂度集中在业务本身而不是浪费在环境搭建和配置上。1.3 “云聘”体系下的用户模型拆解“云聘”这个词除了听起来比“线上招聘”高级一点实际上是要求你把系统设计成多端协同的。绝大多数初学之作的问题就是只做了“单端”即所有的角色都在同一个界面里来回切换。真正合理的设计是“表单 角色权限”双引擎。我比较推荐的做法是用户主表user只保存账号、手机号、密码加密后、邮箱、角色类型student / company / admin等字段。学生信息表student_profile与user表一对一保存姓名、毕业院校、专业、学历、期望城市、期望薪资、技能标签等。企业信息表company_profile与user表一对一保存企业名称、统一社会信用代码、所属行业、规模、简介、营业执照附件路径等。管理员不需要额外表直接在user表里用role字段标记或者用user_role中间表。这样做的好处是登录模块只盯着user表业务模块只关心profile表互不干扰。更重要的是后续你要扩展微信登录、OAuth2这类第三方认证只需要在user表旁边加一张user_auth表就行不会破坏现有结构。权限控制层面我强烈建议用Spring Security JWT的组合而不要图省事自己写拦截器。虽然自己写拦截器很简单但Spring Security的过滤器链机制、PasswordEncoder、Method Security这些功能能给你省掉很多“低级但致命”的安全问题。比如密码加密一定不要用MD5那是二十年前的玩法了用BCryptSpring Security内置支持或者至少用加盐的SHA-256。2. 从“业务流程图”到“数据库表结构”我踩过的坑和最终落地方案2.1 画清楚业务边界比急着建表更重要很多同学拿到这个题目第一反应是打开Navicat开始建表这是大忌。因为业务边界没定表建得再多也是漏的。我自己的做法是先画“三张流程图”第一张是学生端流程注册登录 → 完善简历 → 浏览职位/搜索职位 → 投递简历 → 查看处理状态 → 收到面试邀请 → 接受/拒绝邀请 → 查看面试安排。第二张是企业端流程注册登录 → 企业认证 → 发布职位 → 查看收到的简历 → 筛选简历标记通过/不通过→ 向候选人发起面试邀请 → 查看面试结果反馈。第三张是管理员流程登录后台 → 审核企业认证信息 → 审核职位信息如果有敏感词或违规内容→ 查看平台整体数据注册人数、职位数、投递数等→ 处理举报/反馈。这三张图画完之后你才能知道用户表、简历表、职位表、投递表、面试表、通知表、审核表这些表之间的外键关系到底是什么。2.2 核心表结构设计一句话概括每张表“保底”要有什么字段我不打算把建表SQL全篇贴出来因为那样太长而且每个字段的注释只有你自己知道直接抄的后果就是答辩时被问到“为什么这个字段是varchar(50)而不是varchar(100)”就哑火。这里主要说一下设计思路以及我回顾时觉得容易出问题的几个地方。用户表biz_user主键、用户名、手机号、密码、角色、状态正常/禁用、创建时间。这里需要注意手机号最好设置为唯一索引因为在几乎所有招聘平台中手机号都是登录凭证如果你选了“用户名密码”登录那手机号就是找回密码的关键。学生简历表biz_resume主键、用户ID、姓名、性别、出生日期、最高学历、毕业院校、专业、毕业年份、手机号、邮箱、期望职位、期望城市、期望薪资、技能标签、自我评价、附件简历路径。这里“技能标签”我建议用逗号分隔的字符串存而不是单独建一张标签表并做关系映射。原因很简单毕设阶段标签搜索的复杂度还不值得你引入多对多关系。企业信息表biz_company主键、用户ID、企业名称、统一社会信用代码、法人代表、所在城市、详细地址、所属行业、企业规模、企业简介、营业执照URL、审核状态待审核/通过/驳回、审核备注。职位表biz_job主键、企业ID、职位名称、职位类别、工作城市、薪资范围、学历要求、经验要求、职位描述、招聘人数、投递数量、状态招聘中/已下线、创建时间、过期时间。过期时间这个字段非常关键后面讲定时任务时你会看到它的用处。投递表biz_delivery主键、学生用户ID、职位ID、企业ID、投递时间、简历快照也可以是简历ID、状态待查看/已查看/已筛选通过/已筛选不通过/已邀约面试/已完成、更新时间。这里做“简历快照”或至少关联简历ID的价值在于学生修改简历后企业看到的不应该是投递之后才更新的那份简历。真实招聘中简历快照是法务合规层面的要求。面试表biz_interview主键、投递ID、面试方式线上/线下、面试时间、面试地点/会议链接、面试官、面试状态待确认/已确认/已拒绝/已完成、面试评价、创建时间。通知消息表biz_message主键、接收用户ID、消息类型系统通知/投递反馈/面试邀请、消息标题、消息内容、是否已读、相关业务ID如投递ID、面试ID、创建时间。这套表结构是从“数据库是业务的镜像”这个原则出发设计的。每张表的存在都对应一个明确的行为。如果哪张表你讲不清楚它服务了什么业务场景那它可能就不该建。2.3 状态机设计投递到面试的“状态流转”不能靠直觉投递和面试是招聘平台中最容易出现“逻辑混乱”的部分。最常见的问题是状态值一味靠前端传参后端不加校验。比如学生端已经投递了企业端这条记录还在“待查看”又比如面试已经结束了投递状态还是“待查看”。我的建议是在后端封装一个“状态流转校验器”投递状态deliveryStatus0-待查看1-已查看2-已通过3-已拒绝4-已邀约面试允许的流转路径0 → 1企业查看了简历1 → 2筛选通过1 → 3筛选不通过2 → 4发起面试邀请4 → 5面试完成3、5 为终态不允许再改动。当然状态机在业务实现上不一定要用独立的状态机框架如Spring Statemachine那对毕设来说太重了。你只需要在Service层的update方法里加一个“当前状态是否符合预期流转路径”的判断或者更优雅一点用枚举类把状态和允许流转的目标状态绑定在一起。代码行数不多但能给答辩加分不少。面试官问“如何保证状态不会跳转异常”时你就可以理直气壮地说出这个设计。2.4 简历模块文件上传与预览的“免费高效的方案”简历上传是招聘平台的一个刚需功能。大部分学生会选择把文件传到服务器本地保存一个路径放到数据库里。这个方案没问题但你需要提前想清楚目录规划否则你会被日志、临时文件和上传文件混在一起搞得很崩溃。我当时的目录规划是/usr/local/upload/ /avatar/ // 用户头像 /resume/ // 简历文件pdf, docx, 图片等 /license/ // 企业营业执照然后通过SpringBoot配置一个静态资源映射把/upload/**映射到本地物理路径。这样上传完成后前端直接拼一个URL就能预览或下载文件。但这里要注意一个坑不要直接把文件以Base64形式存数据库不要用blob字段存大文件。虽然演示时没问题但数据库会迅速膨胀且备份、迁移、查询速度都会受影响。文件系统的性价比远高于数据库存储。等到答辩时如果老师问“你这文件存储有考虑安全性吗”你可以回答“生产环境可以迁移到阿里云OSS/MinIO本地存储方案只是为了开发阶段的低成本验证”。这个回答既暴露了你考虑过生产环境又没有给自己挖坑。3. 技术栈选型的“为什么”从SpringBoot到Vue每一环都该讲得出理由3.1 前后端分离还是服务端渲染别只会跟风很多毕设说明书喜欢写“前后端分离架构前端Vue Element-UI后端SpringBoot MyBatis-Plus”。但如果你问作者为什么选这个组合他大概率只说得出“大家都在用”。我个人的建议是做毕设前后端分离可以做但你要能承受联调成本。前后端分离最大的优点是把“页面渲染”和“数据接口”彻底解耦这也更贴近企业里的真实开发流程。但他的代价是你要同时维护两个项目前端环境Node.js、npm、打包和后端环境JDK、Maven、SpringBoot缺一不可。如果你对Vue不熟只知道几个指令我劝你选服务端渲染的模板引擎Thymeleaf会更稳妥因为它的上手曲线低很多而且Java工程师维护起来更顺手。这不丢人SpringBoot对Thymeleaf的支持非常成熟在官方文档里也有大量示例。但如果决定要用Vue我建议你至少要做到能讲清楚Vue的生命周期函数created、mounted、beforeDestroy等和axios拦截器的用途能讲清楚前后端联调时的跨域问题CORS配置能讲清楚打包后如何发布到SpringBoot后面部署章节会重点讲。3.2 MyBatis-Plus与JPA之选为什么我更推荐前者ORM框架的选择也是答辩必问项。我当时的搭配是MyBatis-Plus。原因有三第一MyBatis的SQL可控性很强。虽然它也是ORM但SQL依然是你自己写的或者MP帮你在XML/注解里生成复杂查询比如职位筛选、多表条件分页时你可以精确控制SQL的形状不用担心“1N”这种性能问题。第二MyBatis-Plus提供了大量“省事API”。比如selectPage分页、saveOrUpdate、removeById等等能在写基础接口时节省大量时间。毕业设计的时间本来就紧这些开箱即用的方法能让你把精力腾给业务逻辑。第三国内绝大多数企业的Java项目都在用MyBatis/MyBatis-Plus。你在毕设里用了它答辩时讲“这是我熟悉的技术栈”会更有说服力。至于JPA它的优势在于“领域驱动设计”和“获取关联实体很方便”但在多表Join查询、复杂统计SQL上你需要写出接近原生SQL的JPQL或原生查询反而绕了一圈。招聘平台难免要写不少Join和统计类SQL所以MP更顺手。3.3 权限认证Spring Security JWT的组合拳在毕设中使用Spring Security会让你的项目复杂度上一个台阶但收益非常明显。因为“云聘平台”天然存在三种角色学生、企业、管理员而每种角色的功能边界必须通过权限模型来管控。JWTJSON Web Token在这里扮演的是“无状态认证凭证”的角色。用户登录成功后后端签发一个Token前端存在本地localStorage或Vuex/Pinia里之后每次请求都把它放在Authorization请求头里后端通过过滤器校验Token的合法性并解析出当前用户ID和角色。我的代码结构中权限相关的部分长这样SecurityConfig核心配置类定义哪些路径放行如登录、注册、首页职位列表哪些路径需要认证。JwtAuthenticationTokenFilter继承OncePerRequestFilter拿到请求头里的Token解析、校验、把用户信息放进SecurityContext。自定义UserDetailsService从biz_user表加载用户并注入角色权限。这里最需要注意的一个坑是放行登录和注册接口时千万不要把投递简历、发布职位这类写操作也放行了。我见过有同学图省事把/api/**全部放行只在拦截器里做了登录校验结果等于没做权限控制。企业端接口必须校验角色是company学生端接口必须校验角色是student。3.4 定时任务与“过期职位自动下架”场景热搜词里有“SpringBoot定时任务”说明这多少算一个普遍困扰。在招聘平台中一个非常自然的定时任务场景是职位过期自动下架。公司发布职位时设了“过期时间”到期后职位状态从“招聘中”变“已下线”如果放任不管学生投递了一个已经下线的职位体验极差。SpringBoot中实现定时任务的成本极低在主启动类或配置类上加EnableScheduling然后在某个方法上加Scheduled(cron 0 0 2 * * ?)就可以在每天凌晨两点扫描过期职位。我当时还顺手实现了一个“每日投递统计摘要”的定时任务把前一天每个职位的投递数据汇总成一条消息推送给对应的企业用户。但定时任务最大的问题是如果你的服务是多实例部署同一个任务会被每个实例都执行一遍。毕设阶段用单机部署当然没问题但答辩时最好主动提一句“如果需要高可用可以引入XXL-Job或让任务在Redis分布式锁的保护下执行”这句话能体现你了解生产环境下的问题。3.5 热词里提到的“springboot整合flink”你怎么看有些同学搜SpringBoot的热词顺手看到了“SpringBoot整合Flink”之类的词就会很焦虑觉得自己的毕设是不是少了“实时计算”这个亮点。这个问题要冷静地看Flink是流处理框架适合实时推荐、实时统计这类场景。一个毕业生招聘平台如果真要上Flink通常是用来做“用户行为实时分析”——比如统计学生用户正在浏览哪些职位然后实时调整推荐位。这在真实商业产品里是合理的但在毕设里如果核心功能还没实现完硬上Flink只会把自己坑死。如果你想给“推荐”模块加点亮点又不想引入Flink这种重型框架有几个更实在的方案基于MySQL的简单标签匹配推荐学生技能标签比如“Java, SpringBoot, MySQL”与职位要求标签“Java, Spring, Vue”做交集计算按匹配度排序。基于Elasticsearch的职位搜索推荐引入ES做全文检索、分词匹配和排序能体现你对分布式搜索引擎的理解也比Flink务实得多。如果对分词有兴趣可以考虑用HANLP你热词里也出现了“hanlp分词在springboot”给简历和职位描述做关键词抽取然后走标签匹配。这个实现量也在可控范围内而且很有技术感。一句话优先保证核心业务闭环再用“轻量级加分项”来点缀。不能为了炫技丢了主线。4. 核心功能实现与高频踩坑记录简历投递、搜索、消息通知4.1 简历投递的“幂等性”同一个学生不能对同一职位投两次这个需求很多同学会忽略直到测试时发现简历列表里出现同样两份投递记录才匆匆忙忙加去重校验。其实这在设计投递表时就应该做联合唯一索引ALTER TABLE biz_delivery ADD UNIQUE INDEX uk_student_job (student_user_id, job_id);数据库层面的唯一索引是最保险的防重复手段后端Service里的if (exists)判断只能算第一道防线两者都做才是稳妥的。投递的逻辑其实不难前端点击“投递简历”携带职位ID。后端校验学生是否已完善简历如果没有提示先完善。校验职位是否仍在招聘中status 1 且 未过期。校验是否重复投递唯一索引拦截。创建一条投递记录状态待查看。同步更新该职位的“投递数量”字段1。第4步的同步更新用事务包起来Transactional保证两个表的操作要么都成功要么都失败。4.2 职位搜索只靠模糊匹配还是引入ES毕设阶段用MySQL的LIKE %keyword%做职位搜索是绝大多数人的选择。面试时如果老师问你“为什么不用Elasticsearch”你可以先坦诚在数据量不大、业务搜索层级不深的情况下MySQL索引就够用了。如果老师追问“什么场景需要ES”你要回答当职位数据量达到百万级别、需要多字段组合筛选城市、薪资、学历、技能标签等、相关性排序和分词匹配时MySQL会力不从心此时引入ES做倒排索引才是合适的。如果你还是想找点差异化可以用一个折中方案在MySQL里建立职位关键词索引表把职位名称、技能标签、职位描述分词后的结果存到一张关联表里再通过JOIN的方式筛选。这虽然笨拙但能体现出你对搜索原理的理解。另外一个细节搜索时SQL注入是毕设里最常见的低级错误。用MyBatis-Plus的QueryWrapper.like()时它内部是预编译的没问题。但如果你是手写XML里的${}拼接就会出大问题。这个要是答辩时被指出来印象分会掉很多。4.3 消息通知模块站内信是毕设最现实的选择真实招聘平台的面试通知会用到短信服务阿里云短信、腾讯云短信或邮件服务JavaMailSender这能提高触达率。但这些服务要么需要资质审核要么需要付费毕设阶段做起来比较麻烦而且会增加系统的外部依赖。所以我当时的做法是“站内信 邮件”的双通道设计但默认优先站内信用户登录后首页顶部会显示红色消息小红点即未读消息数。任何状态变更面试邀请、投递被查看、简历被标记不合适等都生成一条biz_message记录。用户点击消息列表可以看到每条消息的详细内容并附跳转链接如跳到面试详情页、投递列表页。这个实现成本很低但效果非常直观。答辩时你可以说生产环境中只需把biz_message的“发送动作”替换成MQ发送短信/邮件的异步消息就能无损扩展。4.4 拦截器与全局异常处理让报错体验不那么“裸奔”很多同学的前后端调不通原因不是业务逻辑错了而是后端一报错就抛了一堆堆栈给前端前端直接白屏或者弹出一段“Cannot read properties of undefined”的英文。这写得很随意很差劲。我的建议是写一个RestControllerAdvice全局异常处理类对几种关键异常做统一封装RestControllerAdvice public class GlobalExceptionHandler { ExceptionHandler(BusinessException.class) public R handleBusinessException(BusinessException e) { return R.error(e.getCode(), e.getMessage()); } ExceptionHandler(MethodArgumentNotValidException.class) public R handleValidationException(MethodArgumentNotValidException e) { // 取出第一条字段校验提示 return R.error(400, e.getBindingResult().getFieldError().getDefaultMessage()); } ExceptionHandler(Exception.class) public R handleException(Exception e) { // 统一兜底日志打堆栈 return R.error(500, 系统异常请稍后重试); } }这样前端axios拦截器里只要response.data.code ! 200就弹出后端的业务提示文案整体就很规范了。这个能力不应该算加分项应该算“基本功”。5. 部署从“能跑”到“能演示”宝塔/Docker与Vue的SPA路由坑5.1 Vue打包放进SpringBoot不是简单扔static就完事刚才说到前后端分离联调时的跨域问题但到了“上线演示”阶段更推荐的做法是将Vue打包后的dist目录放到SpringBoot的src/main/resources/static目录下这样最后只需打一个Jar包里面既提供了前端页面又提供后端API部署极其方便。热词里的“vue打包放进springboot中”说的就是这个操作。但这其中有一个极其经典的坑如果你的Vue应用开启了History模式路由即URL里没有#号刷新一个非首页的路由比如/jobs时SpringBoot会尝试在后端找这个路径的Controller映射结果找不到给你返回404。这是因为前端路由是浏览器端处理后端根本不知道/jobs是什么。解决方案有两个一是写一个Controller把非API路径都转发到index.htmlController public class SpaForwardController { RequestMapping(value {/, /job/**, /company/**}, method {RequestMethod.GET}) public String forward() { return forward:/index.html; } }二是把Vue的路由模式改成Hash模式URL里有#。这样刷新时不会把路径发给后端自然就不会404。我推荐方案一因为它能让你保留“美观的URL”而且在答辩时你还能解释一遍SPA路由原理这也算一个彩蛋。5.2 宝塔Docker演示环境最优雅的姿势热搜词里也有“宝塔docker部署springboot”。演示毕设的时候如果你的项目只是跑在自己电脑的IDEA里一旦网络换了或者电脑休眠了演示就中断了特别尴尬。更稳妥的方式是租一台云服务器学生机很便宜或者有免费试用用Docker部署。我推荐的部署结构是用docker run分别起MySQL和Redis如果用了Redis容器后端SpringBoot应用打成一个Jar包编写Dockerfile构建成镜像前端打包后的dist目录要么已经打进Jar包要么单独起一个Nginx容器。如果用宝塔面板也可以在“Docker管理器”里可视化管理这些容器不需要敲太多命令。宝塔自带文件管理、日志查看、反向代理配置对毕设演示来讲足够省心。需要注意的部署细节MySQL容器的数据卷一定要挂载否则容器一删数据就没了。SpringBoot的application.yml要根据生产环境切换数据源地址和密码我最推荐的方式是用环境变量spring.datasource.urljdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}?useUnicodetruecharacterEncodingutf8。端口只放行必要的那几个比如80或8080MySQL的3306不要暴露到公网否则会被扫描爆破。5.3 一个让你“安安心心演示”的稳定环境Nginx反向代理如果你没有把前端打进Jar包而是前后端分开部署那Nginx反向代理是最好的方式。结构大概是dist目录里的静态文件由Nginx托管/api/**的请求由Nginx转发到SpringBoot的8080端口WebSocket比如你做了在线聊天则需要配置Upgrade请求头。一个最小可用的Nginx配置片段如下server { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这样配置后前端刷新路由时try_files会帮你兜底到index.html不会再出现上面说的404问题。6. 答辩准备的“加分解”除了CRUD你还可以这样讲6.1 把“自动装配”这件事讲到点子上SpringBoot的自动装配是绝对的高频问题。你可以用自己项目里的一个例子来说明比如自定义一个ResumeCounter统计简历完善度的组件你在META-INF下创建AutoConfiguration.imports新版或spring.factories旧版注册ResumeAutoConfiguration在这个自动配置类里通过ConditionalOnClass判断Classpath里有没有某个类通过ConditionalOnProperty判断用户有没有配置某个参数通过Bean(name resumeCounter)注册Bean。当用户引入这个starter时只需要配置resume.counter.enabledtrue这个组件就自动生效。用上面的例子讲“自动装配”比单纯背概念要生动得多老师很容易听出来你亲手写过。6.2 自己的项目里哪些地方能看出你不只是个“API调用者”“这个项目里哪些代码逻辑最复杂”也是答辩常见的“大杀器”问题。你可以准备两三个细节投递状态机的流转校验逻辑你怎么防止状态被非法篡改。简历文件上传时如何校验文件类型和大小如何通过静态资源映射实现访问而不是把文件塞进数据库。职位推荐的简单实现不引入复杂算法而是通过标签匹配度计算相似度并说明再往上一步可以迭代成协同过滤推荐。这三个点都不算硬核但都体现了“你思考过业务边界的异常情况”比“我用了哪些框架”要有说服力得多。6.3 高频追问清单提前打好草稿根据这些年看到的答辩现场我把老师最爱问的问题整理成一个表你可以拿来模拟提问方向建议回答要点为什么选择SpringBoot约定优于配置、自动装配、内置容器、生态成熟能在毕业设计周期内聚焦业务实现你的项目有哪些角色权限如何控制学生、企业、管理员三种角色基于Spring Security JWT通过过滤器拦截Token并解析角色在Service层用注解或代码校验角色权限数据库表如何设计核心关系是什么用户表与简历/企业表一对一职位表属于企业投递表关联学生职位面试表关联投递记录简历重复投递如何控制数据库联合唯一索引 Service层业务校验双层处理定时任务有哪些职位到期自动下架每日投递摘要推送项目如何部署前端打包进SpringBoot单Jar运行演示环境用Docker容器化部署方便迁移接口存在性能瓶颈怎么办优先分析SQL是否命中索引City/Education等筛选字段建联合索引若搜索复杂可扩展Elasticsearch怎么保证密码安全BCrypt加密不能只用MD5数据库泄露时无法直接反解出原文前端包跨域怎么处理开发环境用CORS配置或代理生产环境用Nginx反向代理同源部署这些问题你不一定全被问到但只要准备充分现场就不会冷场。6.4 千万别说这些“过头话”会让老师质疑你“这是我一个人从零开发的”——如果你用了MyBatis-Plus、Vue、Element-UI你就得承认使用了现成框架和组件库这很正常不丢人。但你不能把框架的能力说成自己的原创否则老师让你现场写一段自动配置类你就下不来台。“这个系统很安全”——一个毕设项目没有渗透测试、没有HTTPS、没有严格的速率限制说“很安全”很容易被反问。你可以说“我做了合理的加密、权限控制和参数校验但和商业系统比还有差距”。“生产环境已经部署上线”——大多数毕设只是演示环境如果你说“已上线”老师问域名备案、并发测试、线上数据量你会很难收场。要区分清楚“可部署”和“已上线”。这部分的经验说白了一句话诚实、清晰、有边界感。老师不怕你知道得少怕的是不懂装懂。7. 回顾项目提升空间在哪里后续可以怎么迭代写完一个毕设后最有价值的动作是“复盘”。我复盘这个毕业生线上招聘平台项目后认为有几个明确可迭代的方向引入Elasticsearch重构职位搜索模块。MySQL的LIKE查询做到能用但跟搜索体验还有明显差距。换成ES后可以实现拼音搜索、错别字纠正、同义词扩展、高亮展示这些电商系搜索体验。简历、职位的数据同步做一次双写或监听Binlog也是个可以拿出来讲的技术点。给“推荐”加点智能。目前用标签匹配度做推荐下一步可以引入“基于用户的行为协同过滤”。比如一个Java方向的学生浏览了“上海Java后端开发”这个职位系统还可以推荐其他Java后端学生在看/投递的职位。这就要在数据库表里增加“用户行为日志表”采集浏览、搜索、投递记录。算法上不用特别深一个Jaccard相似度就能起步。引入Redis做缓存与分布式登录态共享。目前JWT是无状态的登录会话状态都扛在客户端。如果加上Redis可以把Token加入黑名单实现强制下线、可以缓存热门职位列表减少数据库查询压力。同时这也是一个可以讲的性能优化点。在线面试模块。标题里写了“求职与面试平台”说明在线面试是一个可能被期待的场景。目前我们只做了“面试邀请 线下时间地点管理”。如果要升级可以接入多人音视频比如腾讯云TRTC、声网Agora、WebRTC自建MCU。但要提醒的是这块工作量和成本都不小作为毕设“演示级”来说自建WebRTC的信令服务器基于Netty/Socket.IO是个不错的中等难度选择。简历解析。很多招聘平台支持“上传Word/PDF简历后自动解析内容填入结构化表单”。这个功能用文本抽取Apache POI、PDFBox 正则或NLP模型HanLP就可以做一个简化版。答辩时讲到这个点很容易让老师眼前一亮。一个毕业设计做到“可用 有亮点 能自洽”就够了。如果时间充裕挑上面1-2个方向深化项目厚度会明显提升。从开发到答辩最大的体会有两点第一不要急着写代码先用文档把业务链路推演明白等你把状态机画完、表关系理顺了后面的开发其实就是“翻译”而已。第二每个技术选型都要能回答“为什么”面试官不一定真的想听你在框架细节上碾压他而是想确定“这个东西你真的用过、真的懂”。希望这篇复盘能给你省掉几周的摸索时间。如果你正在做这个题目祝你的毕设一次通过。