前段时间一位做企业的朋友跟我诉苦说他们公司HR到现在还在用Excel登记候选人简历要么发邮箱、要么丢微信面试结果散落在各种聊天记录里。想上一套招聘系统又信不过市面上的SaaS担心简历数据放在别人服务器上。我说那就自己搭建一套企业级招聘系统把职位、简历、面试、Offer全流程管起来。于是我把之前做过的项目重新整理成一版可以直接落地的完整源码技术栈就是SpringBootVueMyBatis架构MySQL数据库。这篇博文会把整套系统从数据库建模、后端接口、前端交互到部署上线遇到的问题完整串一遍适合想二次开发招聘系统的团队也适合需要真实项目经验的同学参考。1. 为什么企业级招聘系统会选这套技术组合而非微服务全家桶1.1 先理清招聘系统的真实业务边界在动手写代码之前我习惯先把业务边界想清楚。招聘系统不像电商系统那样有千万级并发也不像消息系统那样需要顶尖实时性它本质上是一个企业内部协同工具用户分别对应HR、面试官、部门主管和候选人。它的核心需求其实很集中维护职位信息并发布到内部或对外渠道归集和管理候选人简历让简历在筛选、笔试、面试、Offer、入职等节点之间流转提供权限控制和操作审计避免简历这种敏感数据被无权查看的人获取同时还要能统计招聘漏斗数据。把这些需求落成功能模块就是职位管理、人才库、投递管理、面试安排、Offer审批、用户权限。这也是整套源码的业务骨架。对中小团队来说这个边界已经够用过度设计反而会让项目烂在半路。我见过不少招聘系统项目一上来就规划消息中心、数据中台结果连最基础的简历流转都没跑顺。企业级项目的第一原则是克制先把核心链路做扎实再谈扩展。1.2 选型SpringBoot、Vue、MyBatis、MySQL的实操逻辑选择SpringBootVueMyBatis架构MySQL数据库不是因为这套组合热门而是每个组件都刚好击中我对这个场景的真实诉求。组件我选它的理由和替代方案对比SpringBoot快速搭建REST API内嵌Tomcat天然适配前后端分离相比SSH或SpringMVC大幅减少配置启动和部署都轻量MyBatisSQL可控性高多表关联和复杂筛选容易调优相比JPA/Hibernate不会有“玄学SQL”连表条件自己掌握Vue组件化开发适合简历列表、审批流这类交互密集页面相比React学习曲线更平缓团队容易接手MySQL事务、索引、运维生态成熟简历量级完全够用相比PostgreSQL普及度更高招人维护成本低还有一个很现实的原因这套组合的招聘人才比较好找。企业里招一个既会业务又能把JPA性能玩明白的人远不如招一个熟悉SpringBootMyBatis的Java工程师来得容易。听起来不够“酷”但企业级项目的第一目标是可维护、可持续交付。1.3 完整版源码按什么结构组织我习惯把工程拆成三块后端服务recruit-api、前端应用recruit-web、数据库脚本db/init.sql。后端按Controller-Service-Mapper三层划分避免业务逻辑堆在Controller里前端按页面模块拆分用Vue Router统一管理路由数据库脚本单独放确保任何环境都能一键初始化。这样的结构也是后面章节的展开基础看代码的人不会迷路。2. 数据设计把候选人从投递到入职的状态机建模成表2.1 六张核心表怎么串起招聘流程招聘系统的数据库设计比一般业务系统更需要“状态意识”。我最终保留了六张核心表sys_user、position、resume、apply_record、interview、offer。sys_user系统用户表字段包括id、username、password、name、role、department_id、status角色分为管理员、HR、面试官、部门主管。position职位表记录职位名称、所属部门、招聘人数、工作地点、薪资范围、职位描述、发布状态。resume简历表存储候选人基础信息和简历文件路径、来源渠道。来源渠道一定要保留后面统计各个渠道转化率全靠它。apply_record投递记录表是业务主表关联position_id、resume_id并携带当前状态status。它定义了“某个候选人投递某个职位后到底走到了哪一步”是整套系统状态流转的核心。interview面试表关联apply_record_id、面试官、时间、地点、轮次、评价、结果。offerOffer审批表关联apply_record_id、薪资、入职时间、审批状态承载从发Offer到入职的闭环。这六张表的关系并不复杂但有一个设计很容易被新手做错不要把状态直接写在简历表上。因为一份简历可能投递多个职位不同职位的进度不同必须通过apply_record这种中间主表来承载状态。一个职位可以收到多份投递一份简历也可以投递多个职位所以apply_record天然是查询统计的事实表。2.2 关键字段和状态机设计的几个细节apply_record.status使用int枚举0待筛选、1初筛通过、2笔试阶段、3面试阶段、4录用、5已拒绝、6已入职。每次状态变化都必须写入操作日志表否则HR两个月后复盘时根本看不出这个候选人为什么被淘汰。这里有个实际业务中非常典型的坑面试结果不能直接改apply_record的最终状态。比如候选人一面通过后apply_record上仍然保持“面试阶段”等终面结果出来再统一变更。如果直接把状态和单轮面试绑定一面的通过状态就会覆盖二面的进行中状态整个流程会乱。建表细节方面我再强调几点所有表使用utf8mb4字符集不要用utf8因为简历来源和候选人自述里经常出现Emoji等特殊字符。简历文件路径、面试评价这类长文本字段不用建索引职位、状态、部门等高频过滤字段才建普通索引。apply_record上建议建联合索引(position_id, status)这是简历池和候选人筛选压力最大的查询条件。create_time、update_time统一用datetime由后端统一写入避免数据库时区差异造成时间乱跳。2.3 初始化脚本和演示数据db/init.sql除了建表还插入了默认管理员账号和十几条演示数据。默认账号admin/admin123角色是管理员演示数据包括两三个职位、十份简历、若干投递记录。这样克隆项目后第一件事就能登录系统看到完整效果再逐步替换成自己的业务数据。数据库设计这部分做到位接口层写起来会非常顺畅。3. SpringBoot服务端MyBatis的精髓在于SQL可控3.1 工程搭建和MyBatis基础配置后端工程我用SpringBoot 2.7.xJDK 1.8就能跑兼容性最稳。关键依赖是web、mybatis-spring-boot-starter和mysql驱动。这里特别提醒mybatis-spring-boot-starter的版本要和SpringBoot版本匹配。我用2.3.1配合SpringBoot 2.7.x没有问题如果换成SpringBoot 3.xstarter也需要同步升级到3.0。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependencyapplication.yml里最关键的是数据源配置连接串里的参数一个都不能少spring: datasource: url: jdbc:mysql://localhost:3306/recruit?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.recruit.entity configuration: map-underscore-to-camel-case: true开启map-underscore-to-camel-case后数据库里的apply_record_id能自动映射成Java对象的applyRecordId能节省大量resultMap。但要注意连表查询中如果字段别名不一致仍需要显式定义结果映射。3.2 多条件简历筛选动态SQL的威力招聘系统最常见的一个场景就是条件组合筛选。简历池、人才库、候选人搜索页面本质上都是多个筛选字段的排列组合。我用MyBatis的where和if动态SQL写完之后这个接口被三个页面复用效果非常明显。select idlistResumeByCondition resultMapResumeDetailMap SELECT r.*, p.title AS positionName, a.status AS applyStatus, a.apply_time FROM resume r LEFT JOIN apply_record a ON r.id a.resume_id LEFT JOIN position p ON a.position_id p.id where if testname ! null and name ! AND r.name LIKE CONCAT(%, #{name}, %) /if if testpositionId ! null AND a.position_id #{positionId} /if if testeducation ! null and education ! AND r.education #{education} /if if testworkYearsMin ! null AND r.work_years gt; #{workYearsMin} /if if teststatus ! null AND a.status #{status} /if /where ORDER BY a.update_time DESC LIMIT #{offset}, #{pageSize} /selectwhere标签会自动处理第一个条件前面的AND避免因为字段为空拼出错误SQL。所有参数都用#{}预编译能有效防止SQL注入。复杂的筛选逻辑放在Mapper层而不是Java代码里操作后续加字段、加条件都方便。这是为什么我在三个列表页复用一个接口后维护成本几乎没有增加。3.3 TypeHandler处理枚举、时间和JSON字段的正确姿势MyBatis的TypeHandler是一个容易被忽视但直接影响开发效率的组件。它负责Java类型和JDBC类型之间的双向映射。我在项目里实际使用了两个场景。第一个是Java枚举和数据库int的互相转换比如岗位类型、学历这些固定字典。第二个是简历表里的“技能标签”我在数据库用VARCHAR存JSON数组通过自定义TypeHandler在存取时自动完成List 和JSON字符串的转换。自定义TypeHandler其实不难继承BaseTypeHandler在setNonNullParameter里把枚举转换成int在getNullableResult里根据int还原枚举。配到Mapper文件的columnType后写业务代码的人完全感觉不到转换过程实体类继续用枚举数据库存int中间细节对上层透明。这也是MyBatis面试题里经常出现的考点但实际项目不要为了炫技而过度使用简单场景直接用Integer字段也完全合理。我的原则是如果转换逻辑在项目里出现了三次以上才适合抽象成TypeHandler。3.4 统一返回结构、参数校验和全局异常服务端不能只把CRUD写完就结束。我在项目里统一封装了Result 返回结构所有接口都返回code、message、data前端拿到code不为0就统一弹出错误提示。全局异常处理用RestControllerAdvice捕获业务异常和数据库异常防止堆栈信息直接暴露到页面。参数校验用javax.validation的NotNull、Size等注解在Controller入参上加Validated。职位发布和Offer审批这类写操作非法状态要在最前面拦截避免脏数据进库。这些设计看起来不直接产生业务功能却是“企业级”三个字真正落地的关键。前端拿到稳定的返回结构联调速度快很多也省去大量重复的if判断。4. Vue前端把招聘状态流转变成好用的交互界面4.1 环境搭建从Node版本到Vite初始化前端用的是Vue3 Vite Element Plus。第一次搭建最容易卡住的地方是Node版本和包管理器。我建议Node 16.20或者18太老的Node跑不动Vite。初始化命令如下npm create vitelatest recruit-web -- --template vue cd recruit-web npm install npm run dev如果npm install慢得离谱就换国内镜像源。接下来安装Element Plus、Vue Router、Pinia和axiosnpm install element-plus element-plus/icons-vue npm install vue-router4 pinia axios开发阶段还需要配好Vite的代理让前端/api请求直接转发到后端的8080端口export default defineConfig({ server: { proxy: { /api: http://localhost:8080 } } })4.2 路由设计、权限守卫和路由传参页面结构是典型的后台管理布局登录后进入带侧边栏的主框架菜单包含看板、职位管理、简历池、投递管理、面试安排、Offer管理、系统设置。不同角色看到不同菜单。前端权限不能用“能看就能用”的逻辑但至少可以拦截大多数误操作。路由守卫写在router.beforeEach里统一检查登录状态和角色router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path ! /login !token) { next({ path: /login, query: { redirect: to.fullPath } }) return } if (to.meta.roles !to.meta.roles.includes(localStorage.getItem(role))) { next({ path: /403 }) return } next() })路由传参在这个系统里也很有用。从职位列表点击“查看候选人”时我直接通过路由query带上positionId简历池页面在初始化时读取该参数并作为筛选条件。这样页面刷新后参数不会丢失也不用把所有状态都堆在sessionStorage里。4.3 简历列表的筛选交互和分页简历池是前端最复杂的页面之一顶部筛选栏包含姓名、职位、学历、渠道、状态中间是简历表格底部是分页。筛选条件变化时我用一个searchForm对象统一收集参数再拼到请求里。为了防止输入姓名时每敲一个字母都发一次请求我加了300ms防抖实际体验顺畅很多。分页用Element Plus的el-pagination接口返回total请求参数传current和pageSize。这里有一个很容易踩的坑筛选条件一变页码必须重置成1否则用户从第二页筛选时可能查不到数据或者出现空页。我一开始就漏了重置后来在watch里对searchForm统一处理页码才解决。4.4 简历上传、预览和附件的处理简历来源不只有在线填写还有大量PDF和Word附件。上传组件用el-uploadaction指向后端接口。不过有一点要注意上传请求不能像普通请求那样简单带token需要手动拼接请求头而不是把token塞进FormData。后端的XSS过滤器还要单独放行上传接口否则二进制文件流会被过滤器破坏这个问题我在下一节细说。附件预览我采用了“后端出具获取接口”的方式。文件保存到服务器非public目录前端请求附件接口时带上鉴权参数后端校验权限后返回文件流。这样简历不会被人用猜路径的方式直接下载。5. 上线前一定要绕开的坑XSS过滤器、MyBatis缓存、MySQL时区与Nginx 4045.1 全局XSS过滤器不能一刀切地过滤所有请求做安全审查时我发现候选人的自我介绍和职位描述都支持富文本如果原样存储一段带onerror属性的内容在后台打开时就可能触发脚本。正统做法是加一个全局XSS过滤器对请求参数做HTML转义和危险关键字过滤核心是自定义HttpServletRequestWrapper重写getParameter和getInputStream。但真正的坑在于不要把所有请求都过滤一遍。multipart/form-data文件上传请求如果强制读取内容去检查XSS小文件还勉强大文件会把整个二进制流读进内存性能和稳定性都会出问题PDF文件流被过滤后甚至会损坏文件。我的做法是ContentType以multipart/开头直接放行白名单路径放行剩余请求再做参数清洗。富文本字段允许保留p、br、strong、a这类安全标签但统一剔除script、iframe和以on开头的所有事件属性。这样才算既安全又不影响业务。5.2 MyBatis缓存本项目中我选择关闭二级缓存MyBatis一级缓存是SqlSession级别的同一个会话内重复查询不查库问题不大二级缓存是Mapper级别的跨会话共享问题就麻烦。项目早期为了减少数据库压力开过二级缓存结果踩了一个典型坑两位HR同时操作候选人状态因二级缓存保留了旧数据列表页读出来的一直是过期的状态数据持续不一致。排查到最后根因就是缓存没有及时刷新。招聘系统查询条件多、状态更新频繁二级缓存的收益很不稳定远不如直接优化SQL和依赖连接池兜底。最终我把mybatis.configuration.cache-enabled改成false彻底关闭二级缓存。如果你被问到MyBatis缓存能说出这个取舍和实际场景往往比背一遍面试题更有说服力。5.3 MySQL 8连接时区报错这个问题很基础但出现频率极高mysql-connector-j 8.x连接数据库时不指定serverTimezone启动阶段大概率报The server time zone value is unrecognized。我在连接串里写成serverTimezoneAsia/Shanghai而不是GMT%2B8。后者在部分Linux环境下解析仍可能出错。另外连接池配置里我习惯让初始化连接执行一次SELECT 1保证连接真正可用后再交给业务使用。5.4 Vue Router刷新404开发模式下看不出问题前端打包部署到Nginx后刷新简历详情页就会出现404。原因是Vue Router使用了history模式前端路由由JS接管而Nginx只认物理存在的路径。解决办法是让所有未匹配的路径回退到index.htmllocation / { try_files $uri $uri/ /index.html; }这个配置必须放在静态文件服务的root之下然后把/api单独反向代理到SpringBoot。我见过同事把try_files和proxy_pass的顺序写反结果刷新404和接口404同时出现排查了大半个晚上。顺序问题记清楚就能避开。6. 部署交付让“完整版”从源码变成可运行系统6.1 在一台干净服务器上的运行顺序给出一套可以直接照做的部署步骤安装JDK 8、MySQL 8、Nginx、Node 16及以上版本。创建数据库recruit_db执行db/init.sql导入表结构和演示数据。后端目录执行mvn clean package -DskipTests生成recruit-api.jar。前端目录执行npm run build把dist目录上传到服务器。复制jar包到部署目录用nohup java -jar recruit-api.jar app.log 21 启动。配置Nginx静态文件root和/api反向代理执行nginx -s reload。浏览器访问服务器IP用演示账号登录验证。这套流程我已经在新环境实测过整个过程中最容易卡住的就是MySQL连接串和Nginx的try_files先按上面配置好基本能一路顺畅跑通。6.2 配置分离和环境变量不建议把数据库密码直接写在application.yml里再提交到源码。完整版源码里我只提供示例配置密码用占位符处理password: ${DB_PASSWORD:123456}部署时通过环境变量注入真实数据库密码。这样源码即使被二次分发核心凭证也不会裸奔。配置分离是企业级项目的基本意识也顺便养成了好习惯。6.3 后续可以扩展的几个方向如果业务量增长这套源码可以从几个方向延伸招聘门户H5把职位列表做成公开接口对接招聘官网和微信生态后端只需增加渠道来源字段人才库运营把某个职位淘汰的简历保留进人才库后续挖猎时再捞回招聘漏斗看板基于操作日志做渠道转化率统计SQL层加几个聚合查询就能出报表消息通知接入邮件和短信服务发送面试邀约和Offer通知接口层增加异步消息队列消费即可。如果说我在这套系统上最大的体会那就是“完整版源码”不等于堆功能而是让其他人clone下来后能跑通、能改得动、上线后不翻车。我的做法是业务边界尽量清晰技术选型尽量保守落地前把容易踩的坑提前处理干净。实际运行中我还坚持把所有状态变化沉淀成操作日志做到任何候选人的流转轨迹都能回溯。如果你正准备做类似的招聘系统不妨先从简历表、投递记录和状态流转这三块理清楚再开始写页面代码整个开发过程会顺得多。