1. 项目概述为什么还要做一个招聘求职系统先交代一下背景。我之前在某软件公司带团队做企业级应用开发这两年接到过好几个和在线招聘沾边的需求——有做内部人才库的有做校企对接平台的也有帮人力资源公司做简历流转管理的。接得多了我发现自己手里攒了一套比较通用的设计思路正好最近又完整地做了一个javavue基于springboot框架的在线招聘求职系统就把整个从零到一的过程整理出来希望能给准备做同类项目的同学一点参考。这个系统解决的核心问题其实很朴素传统的招聘流程里企业发职位靠张贴和群发求职者投简历靠海投和碰运气两边信息不对称沟通效率极低。在线招聘系统要做的就是搭一座桥——企业侧能发布职位、筛选简历、发起面试邀约求职者侧能完善简历、检索职位、在线投递、跟踪进度平台侧能管理用户、审核职位、统计分析。技术上走的是主流的前后端分离路线后端JavaSpring Boot提供REST接口前端VueElement UI做单页应用数据库用MySQL缓存用Redis。这个技术组合在2024年前后依然是中小型Web系统里最稳妥的选择之一。Spring Boot省掉了大量繁琐的XML配置内置Tomcat微服务时代的各种starter拿来即用Vue的组件化开发配合Element UI的后台组件库做管理类界面效率非常高。如果你正在学Spring Boot或者Vue想找一个完整的全栈练手项目本文的整套方案基本可以照着敲。我会把涉及到的核心设计思路、数据库表结构、接口约定、前端页面组织、权限控制、部署注意点一步步拆开讲重点放在那些网上教程很少提到但实际开发一定会踩的坑上。2. 整体架构与方案选型分析2.1 前后端分离的总体结构我做这个系统时第一个定的原则就是前后端彻底分离。前端工程单独部署通过HTTP请求调用后端API两边只通过JSON交换数据。这样做的直接好处是前端开发可以完全不依赖后端环境后端接口写好Mock数据就能并行推进后期如果要做小程序端或者App端后端接口几乎不用改动直接复用同一套API。后端工程按传统的分层结构组织Controller层只负责参数接收和结果封装Service层处理业务逻辑Mapper层用MyBatis操作数据库。我额外加了一层DTO/VO的转换不让数据库实体直接暴露给前端这样即使表结构调整接口返回值也可以保持不变。整个后端包名我习惯这样划分controller接收请求、参数校验、调Serviceservice业务逻辑、事务控制mapperMyBatis数据访问接口entity数据库实体类dto入参对象接收前端数据vo出参对象返回给前端的数据config配置类拦截器、跨域、Redis等common统一返回结果、异常处理、工具类前端工程用Vue CLI 3.x构建路由用Vue Router状态管理用VuexUI组件库选Element UIHTTP请求统一封装在单独的request.js里基于axios做了拦截器处理token注入和错误提示。2.2 为什么选Spring Boot MyBatis Redis这套组合很多初学者会纠结到底用JPA还是MyBatis我的建议是做这类偏传统的管理信息系统MyBatis更顺手。原因很简单招聘系统里有大量多表联查和条件动态拼接的场景比如职位搜索要同时关联公司信息、过滤薪资范围、排序发布时间MyBatis的XML里写动态SQL非常直观控制力强。JPA在小项目里确实省事但一旦查询复杂起来方法名推导和自动SQL反而变成束缚。Redis在这里的定位是加速器不是数据库替代品。我用Redis存三类数据登录token替代传统Session支持分布式扩展、首页热门的职位列表缓存、验证码的临时存储。这些都是典型的高频读、低一致性要求的场景放Redis非常合适。MySQL的存储引擎用InnoDB字符集统一utf8mb4因为简历和自我介绍里可能会出现生僻字或特殊符号utf8mb4才能完整覆盖。2.3 部署形态与运行环境系统最终部署我采用的方案是一台Linux服务器Nginx监听80/443端口负责静态资源托管和API反向代理后端打jar包用systemd托管运行MySQL和Redis各自独立服务。整个拓扑非常精简但从实际运行情况看支撑几千人的校园招聘场景完全没有压力。开发调试阶段不用这么麻烦Windows本机装一个MySQL 8.0和一个Redis即可后端IDE用IDEA前端用VS Code。下面所有内容我都按本地开发环境的角度来写最后再单独讲生产部署的特殊处理。3. 数据库设计招聘系统的地基3.1 核心表结构总览我在设计表结构时反复推演过业务流程最终确定了9张核心表。如果你之前没做过类似系统我建议先画一张简单的业务流转图再动手建表不然很容易出现字段冗余或者关联关系混乱。核心表清单sys_user用户主表区分求职者、企业管理员、平台管理员三种角色company企业信息表和企业管理员用户一对一resume简历表和求职者用户一对一position职位表和企业一对多delivery_record投递记录表记录求职者投递职位的行为和状态流转favorite收藏表求职者收藏心仪职位interview面试邀约表企业HR对投递者发起面试安排resume_education / resume_work简历的子表存教育经历和工作经历sys_user表的设计我放出来重点说一下。用户名、密码、手机号这些常规字段肯定要有但角色字段我用的是role_codeString类型而不是简单的is_admin布尔值。因为系统有三类角色用布尔值根本表达不了用整数1/2/3也很容易混淆。role_code直接用字符串可读性最好candidate代表求职者company代表企业管理员admin代表平台管理员。3.2 职位表与投递记录的动态设计position职位表是整个系统查询压力最大的表字段设计上要兼顾列表展示和条件筛选。基础字段包括职位名称、职位描述、所属公司ID、薪资下限、薪资上限、工作城市、工作经验要求、学历要求、职位标签、招聘人数、发布状态、浏览量、创建时间。这里有三个字段是很容易被忽略的work_city我存的是城市编码而不是中文名。前端下拉框展示中文提交时传编码后端存编码。这样做的好处是以后做地区维度统计时可以直接GROUP BY不用做字符串匹配。salary_min和salary_max分开存两个整数而不是存一个s薪资区间。道理一样查询时可以用between做区间过滤排序时也能按最低薪资排序。position_status0草稿、1招聘中、2已下线。前端企业端只能看到自己发布的职位平台端可以看全部状态字段就是用来做这些权限过滤和列表展示的。投递记录表delivery_record值得单独拎出来讲因为它是整个系统里状态流转最复杂的表。每一行记录代表一次投递行为核心字段有delivery_id、candidate_id、position_id、company_id、status、create_time、update_time。这里我把company_id冗余进去了虽然通过position可以关联查出company但投递记录列表在求职者端和企业端都会高频按company维度或position维度查询冗余一个字段能减少一次JOIN查询速度明显更快。投递状态status用整数维护我定义了一套完整的流转规范1已投递求职者发起投递时写入2被查看企业HR点开简历详情时更新3通过初筛HR标记合适4不合适HR标记不合适5已发面试邀约HR发起面试6已录用面试通过后发offer每个状态之间不是随意跳转的后端Service层要做状态机校验。比如已录用的记录不能被改回已投递已不合适的记录不能再发面试邀约。这些校验逻辑初期可能觉得啰嗦但上线之后会发现它能挡住大量脏数据。3.3 简历表和面试邀约表的处理方式resume简历表用主表子表的模式。主表存的是简历的基础概览信息姓名、性别、出生年份、手机号、邮箱、期望职位、期望城市、期望薪资、个人简介、头像地址、创建时间、更新时间。子表resume_education存教育经历resume_work存工作经历。为什么要把经历拆到子表而不是用JSON字段一把梭我解释一下。JSON字段在MySQL 5.7以后虽然也能支持但查询、统计、排序都不方便。比如系统以后要做按学校筛选候选人的功能如果教育经历是JSON嵌套存的话SQL都写不出来。拆成子表查询、修改单条经历、排序都干净利落代价只是多写一点关联代码非常值得。面试邀约表interview则是招聘流程的末端环节。字段包括邀约ID、投递记录ID、面试时间、面试地点或线上会议链接、面试官姓名、联系方式、备注说明、状态待确认/已接受/已拒绝/已完成、创建时间。这里我用投递记录ID做外键关联而不是直接用候选人ID和职位ID因为面试邀约一定是针对某一次投递行为的这样可以避免同一候选人对同一职位投递多次后邀约归属混乱的问题。4. 后端Spring Boot核心实现认证、权限与业务接口4.1 统一返回结果与全局异常处理后端接口设计的第一件事就是统一返回格式。我定义了一个R对象作为所有接口的返回包装结构如下Data public class RT { private Integer code; private String message; private T data; public static T RT ok(T data) { RT r new R(); r.setCode(200); r.setMessage(success); r.setData(data); return r; } public static T RT fail(String message) { RT r new R(); r.setCode(500); r.setMessage(message); return r; } }code我用200表示成功非200表示失败。前端axios拦截器里统一判断code是否为200不是的话直接弹出message。这里要特别注意HTTP状态码我全部返回200真正的业务状态放在code字段里。这么做看起来反直觉实际开发中却能省掉很多麻烦。比如参数校验失败时HTTP状态码可以是200但code返回500前端只需关注业务code。如果严格依赖HTTP状态码团队里还要约定4xx、5xx的各种语义沟通成本高不如统一走业务码简单直接。全局异常处理我用RestControllerAdvice实现。所有Service层主动抛出的业务异常统一捕获返回给前端友好的提示信息未知的系统异常在日志里打印完整堆栈但返回给前端的message统一是系统繁忙请稍后重试。这一步极其重要否则数据库字段超长、空指针这类低级错误会被原样返回给前端既暴露系统内部结构用户体验也很差。4.2 基于JWT Redis的登录认证方案登录认证我选择JWT Redis的组合方案替代传统的Session。流程是这样用户提交账号密码或者手机号验证码后后端校验通过生成一个UUID作为token以token为key、用户基本信息为value写入Redis设置有效期同时发一个带签名信息的JWT给前端里面包含userId和过期时间。前端拿到JWT后存到localStorage每次请求在Header里带上Authorization: Bearer {token}。后端用一个拦截器统一校验JWT的签名校验通过后从Redis里查询token是否还有效有效则放行并往ThreadLocal里写入当前用户ID后续Service层直接从ThreadLocal取值省去了参数传递的麻烦。这里有个细节值得注意JWT我主要用它来做签名防伪真正的会话状态还是放在Redis里。网上有些文章喜欢把用户信息全部塞进JWT里做到无状态认证但这在实践中有个问题——如果用户修改了手机号、被管理员封禁、或者要强制退出登录光靠JWT无法立即让旧token失效。而加了Redis这一层注销时把Redis里的token删掉就完事了可控性强很多。拦截器的实现大概长这样Component public class LoginInterceptor implements HandlerInterceptor { Autowired private StringRedisTemplate redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); String userJson redisTemplate.opsForValue().get(login:token: token); if (userJson ! null) { // 解析用户信息存入ThreadLocal LoginUserContext.setUser(JSON.parseObject(userJson)); return true; } } response.setContentType(application/json); response.setCharacterEncoding(UTF-8); response.getWriter().write(JSON.toJSONString(R.fail(未登录或登录已过期))); return false; } }角色权限控制我做了两级。第一级是登录校验所有需要登录的接口都会被拦截器拦住第二级是角色校验用Spring拦截器配置不同的pathPattern指定某些接口只允许特定角色访问。比如/admin/**下所有接口只允许平台管理员角色/company/**只允许企业管理员角色候选人相关的则只允许candidate角色。4.3 职位搜索的场景化SQL实现职位搜索是整个系统后端最核心的业务接口。前端搜索页会有多个筛选条件关键字、城市、薪资范围、工作经验、学历要求、排序方式。这些条件不是固定的用户可能只填其中一个也可能全部不填。这就非常依赖MyBatis的动态SQL能力。我给出的mapper实现核心片段如下select idsearchPositions resultTypecom.example.vo.PositionVO SELECT p.id, p.title, p.salary_min, p.salary_max, p.work_city, p.experience_require, p.education_require, p.industry, p.position_status, p.create_time, c.company_name, c.company_logo, c.company_size FROM position p LEFT JOIN company c ON p.company_id c.id where if testkeyword ! null and keyword ! AND (p.title LIKE CONCAT(%, #{keyword}, %) OR p.description LIKE CONCAT(%, #{keyword}, %)) /if if testcity ! null and city ! AND p.work_city #{city} /if if testminSalary ! null AND p.salary_max gt; #{minSalary} /if if testmaxSalary ! null AND p.salary_min lt; #{maxSalary} /if if testexperience ! null AND p.experience_require #{experience} /if if testeducation ! null AND p.education_require #{education} /if AND p.position_status 1 /where ORDER BY p.create_time DESC /select薪资筛选这里有一个细节如果用户选择的是10k-15k前端传过来的minSalary10、maxSalary15SQL里判断的是职位的薪资区间和用户期望区间是否存在交集。也就是position.salary_max 10 AND position.salary_min 15这样两个区间有重叠就说明匹配得上。如果用position.salary_min 10这种写法就会漏掉12k-18k这种实际完全符合要求的职位。还有一点索引设计上position表主要查询字段是position_status、create_time、work_city我为这三个字段建了复合索引(work_city, position_status, create_time)。实测在20万条职位数据量下搜索接口的响应时间从平均800ms降到了120ms左右效果非常明显。4.4 投递流程与简历查看逻辑投递接口的流程设计我建议走校验-落库-通知三步。第一步校验判断当前登录用户是否有一份完整度超过80%的简历如果没有直接返回请先完善简历后再投递判断这个用户是否已经投递过该职位如果投递过返回请勿重复投递。第二步落库插入一条delivery_record记录状态置为1同时把position表的投递数加1。第三步发通知往消息表里插入一条企业侧的通知记录让企业端HR在消息中心能看到XX投递了您的职位XX。简历查看是投递闭环的另一半。企业HR在投递列表里点击某个候选人时前端调用后端接口获取简历详情。这个接口有个重要的业务点这一次查看行为会把对应投递记录的状态从1改成2表示被查看。同时后端要记录查看时间避免纠纷时无据可查。简历详情接口的数据组装比较复杂它需要把resume主表、resume_education子表、resume_work子表的数据聚合到同一个VO里返回。我在Service层做了明确的分工先查主表信息再分别查两个子表最后组装成ResumeDetailVO。从性能角度考虑这里不能用循环去查子表会产生N1问题而应该先用简历主表ID批量查出所有教育经历和工作经历再在内存里按简历ID分组组装。5. 前端Vue实现页面组织与关键交互5.1 前端工程目录与路由权限设计前端工程我按业务域拆模块开发者目录如下src/ api/ // 接口请求模块按领域拆分 auth.js position.js resume.js delivery.js company.js admin.js assets/ // 静态资源 components/ // 通用组件 GlobalHeader.vue CompanyItem.vue PositionCard.vue layout/ CandidateLayout.vue CompanyLayout.vue AdminLayout.vue router/ index.js permission.js store/ modules/ user.js views/ candidate/ position-search.vue position-detail.vue resume-edit.vue delivery-list.vue favorite-list.vue company/ company-info.vue position-manage.vue delivery-manage.vue interview-manage.vue admin/ user-manage.vue position-audit.vue statistics.vue login.vue register.vue utils/ request.js auth.js路由权限上我在Vue Router的beforeEach守卫里做了登录态和角色双重判断。每个路由的meta字段里声明了allowedRoles数组用户登录后把角色信息存进Vuex路由跳转时先检查是否登录再检查角色是否匹配。不匹配的统一跳转到403页面。这里有一个非常容易踩的坑路由守卫里不能只在前端做权限校验后端接口也必须做同样的校验。因为前端的路由控制只是提升体验懂技术的人完全可以直接调用后端API绕过前端页面。所以后端每个接口都要验证当前登录用户的角色是否有权限访问前端路由控制只是锦上添花后端的接口权限才是真正的安全底线。5.2 职位搜索页和职位详情页的实现细节职位搜索页我用了筛选区列表区的经典布局。筛选区顶部是关键字搜索框下面是城市、经验、学历、薪资下拉筛选列表区用卡片式布局展示职位信息卡片分页组件在列表底部。这里我踩过一个交互设计的坑最初把城市筛选做成了下拉框但城市列表太长全国几百个城市用户要找特定城市需要滚动很多次。后来改成远程搜索的Select输入框输入关键词动态匹配城市实测使用体验提升明显。Element UI的el-select自带远程搜索能力配合一个mock的城市接口就能实现成本很低。职位详情页的逻辑要稍微复杂一点。页面顶部展示职位基本信息和企业信息中部分两块区域职位描述和企业介绍底部是一个固定的投递操作栏。判断投递按钮的文案和可用状态前端需要调用后端的一个预检查接口返回当前用户对该职位的投递状态未投递、已投递、已下线。根据状态渲染立即投递、已投递置灰、职位已下线置灰。简历的投递按钮点击后前端要弹出确认框提醒用户确认投递该职位投递后企业方可查看您的简历。确认后调用投递接口成功后前端不仅要跳转到投递列表页还要同时把页面上的投递状态更新掉避免用户重复提交。5.3 企业端的投递管理页面企业端投递管理是最能体现系统价值的地方。页面默认展示当前企业所有收到的投递记录按投递时间倒序排列每条记录显示候选人姓名、投递职位、投递时间、当前状态。我建议在投递管理页面增加一个筛选Tab栏全部、待查看、已查看、已邀约、已录用、已淘汰。每个Tab对应投递记录状态的一个或几个取值前端切换Tab时调用后端不同的查询接口数据的筛选逻辑放在SQL里做而不是前端过滤。在企业数据量稍大时前端全量拉取再过滤的方式会导致页面渲染变慢几十条还好几百条就会明显卡顿。列表里每一行右侧提供操作按钮组根据状态动态展示。比如待查看状态显示标记合适、标记不合适、查看简历三个按钮已邀约状态显示查看面试详情按钮。面试邀约操作会弹出一个Dialog表单填写面试时间、地点、备注提交后调用后端接口后端会同步更新投递记录的状态并给求职者端发一条消息通知。5.4 简历编辑器和权限互斥处理简历编辑器是求职者端最复杂的页面。我用了分步表单结构从上到下依次是个人信息、教育经历可多段、工作经历可多段、求职意向和技能标签。教育经历和工作经历都支持增加多条和删除多条。多条经历的数据结构我在前端用了一个数组来维护每次增删操作都同步更新数组。提交时统一提交整个简历对象后端要么整体更新成功要么整体失败保证数据一致性。这个全量提交的方式在简历这种低频编辑场景下完全够用不需要做到字段级别的增量更新。前后端分离开发中一个很容易翻车的问题是角色互斥。比如企业管理员登录后理论上不应该有求职者端的功能。我在前端做了双重保险路由元信息控制页面可见性菜单渲染时根据角色过滤可访问项。但从实际效果来看还会出现一种特殊情况企业管理员确实没法看到求职者端的页面但如果他直接访问求职者端的API接口后端还是会放行因为JWT鉴权只检查了登录态没检查角色。所以我在这类接口上加了一个自定义注解标注该方法只允许哪种角色访问在Service层做二次校验之后这个问题才彻底解决。6. 部署发布与运行效果6.1 本地全量启动配置清单如果你是照着这个项目自己写的本地启动需要准备的环境如下组件版本用途JDK1.8后端运行环境Maven3.6后端依赖管理MySQL8.0主数据库Redis5.0会话与缓存Node.js14前端构建Vue CLI4.x前端工程脚手架后端application.yml里的关键配置项我列一下这些参数在网上能搜到一大堆但踩过坑的人才知道哪里要特别注意server: port: 8080 servlet: context-path: /api spring: datasource: url: jdbc:mysql://localhost:3306/recruit_system?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: yourpassword redis: host: localhost port: 6379 database: 0 mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplcontext-path全部配置为/api这样前端开发环境的axios请求baseURL设为/api能直接复用一个开发代理配置。前后端联调时用Vue的devServer代理方式把请求透传到后端8080端口我贴一下vue.config.js里的配置module.exports { devServer: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };changeOrigin必须设置为true否则后端拿到的请求Host是前端地址一些基于Host的判断逻辑比如某些安全框架的csrf校验会出问题。MyBatis的驼峰映射必须开启否则数据库里create_time这种下划线字段映射不到实体类的createTime属性上查出来的值就是null这种问题排查起来极其痛苦。日志开启到stdout级别只建议在开发环境用生产环境一定要关掉不然SQL日志会把接口响应速度拖慢不少。6.2 生产环境的差异化配置生产环境和本地开发有几处必须不同的地方。数据库密码不能明文写在配置文件里我用的方案是Jasypt加密把密文写在yml里启动时通过JVM参数传入解密密钥。MySQL连接串需要加上useSSLfalse和allowPublicKeyRetrievaltrue这两个参数。MySQL 8.0默认的认证插件是caching_sha2_password不加allowPublicKeyRetrievaltrue的话首次连接需要额外的RSA公钥交换一些连接池在初始化阶段会报错。这两个参数在我处理过的生产事故中出现频率非常高提前写上去能避开很多麻烦。后端打包用Maven的package命令生成可执行jar启动命令如下nohup java -jar recruit-server.jar --spring.profiles.activeprod server.log 21 Nginx前端配置的核心片段server { listen 80; server_name yourdomain.com; # 前端静态资源 location / { root /opt/recruit/frontend; index index.html; try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; 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这是Vue Router使用history模式时的必要配置。如果前端用的是hash模式URL里带#则不需要这一行。我在项目里用的history模式URL更干净但必须依赖Nginx做这个回退处理否则刷新子页面就是404。6.3 线上运行的效果与注意事项系统上线后我持续观察了一段时间的运行数据。单台4核8G的云服务器同时承载MySQL、Redis、后端服务和Nginx白天高峰期的接口平均响应时间在200ms到400ms之间QPS峰值大概在100左右整体稳定。不过有几件事必须提醒你注意。第一个是文件上传的目录要单独配置不能随便放在临时目录。系统里用户头像和公司Logo都涉及文件上传我把上传目录配成了/data/recruit/upload并在Nginx里加了一个静态映射让访问/upload/xxx.jpg能直接找到对应文件。如果没有提前规划好上线后所有图片都可能因为重启丢失。第二个是数据库连接池的配置。我建议最大连接数设置在50到80之间最小空闲连接数10个左右并加上连接存活检测。Spring Boot 2.x之后默认用的是HikariCP配置非常简洁spring: datasource: hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 30000 idle-timeout: 600000第三是定期备份数据库。我写了一个简单的cron脚本每天凌晨3点执行mysqldump全量备份保留最近7天的备份文件。系统本身跑得再稳也扛不住某天手滑误删数据备份是最好的后悔药。7. 常见问题与排错实录7.1 前后端联调时的CORS跨域问题前后端分离项目里第一个会碰到的坑就是跨域。前端运行在http://localhost:3000后端运行在http://localhost:8080浏览器直接发ajax请求一定报跨域错误。用代理模式开发时是不会有跨域问题的因为浏览器看到的请求目标是同源的3000端口代理在服务端转发了请求。但如果不加代理直接请求后端地址就必须在后端配置CORS策略。我这里给出Spring Boot的CORS配置方式用WebMvcConfigurer加全局配置注意allowedOriginPatterns这个方法名不同Spring Boot版本有差异旧版用allowedOrigins新版要用allowedOriginPatternsConfiguration 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配套allowedOriginPatterns使用才能正确处理带Cookie的请求。虽然我们项目主要用JWT不依赖Cookie但保险起见还是保留了这行。Electron或某些移动端WebView场景下你会发现前端的Origin可能表现为file://或者nullallowedOriginPatterns(*)可以兼容这种情况。但如果你的业务对安全性要求很高建议在生产环境把allowedOriginPatterns收窄到具体的域名白名单而不是通配放开。7.2 登录接口报401/405的处理登录后访问业务接口报401最常见的原因是前端没有在每次请求的Header里带上token。我们需要在axios的请求拦截器里统一注入这段代码我贴在下面// request.js import axios from axios import { getToken, clearToken } from /utils/auth import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token getToken() if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message) if (res.code 401) { clearToken() router.push(/login) } return Promise.reject(new Error(res.message)) } return res.data }, error { Message.error(网络请求异常) return Promise.reject(error) } )登录接口本身是匿名接口不经过token校验所以登录成功后一定要立刻调用一次获取用户信息的接口把user对象存到Vuex里然后才能根据user对象中的角色信息按需渲染菜单和路由。如果你遇到的是405大概率是请求方式不匹配。我排查过好几次把POST写成了GET或者后端接口方法上没有标注明确的RequestMethod。Spring Boot接口层如果忘了指定method默认是匹配所有请求方式的但如果你在RequestMapping或PostMapping等注解上写死了方法另一种方式请求就会返回405。这个错误信息是HTTP层面的不会进到我们自己的业务异常处理里所以排查时要先看浏览器Network面板里报错的状态码再对应处理。7.3 投递记录出现重复数据上线后我遇到过一个真实的线上问题用户快速连点两次立即投递按钮结果产生了两条投递记录。排查发现前端虽然做了按钮置灰但置灰操作是在接口响应之后才执行的第一次请求还没返回时用户已经点了第二次两次请求都到后端了而后端的重复校验也放行了。这个场景的根因是先检查再插入的竞态条件。解决的办法有三个层面我建议同时做。第一层前端点击后立即把按钮状态改为loadingPromise执行期间禁止再点。第二层后端在delivery_record表上加一个唯一索引把candidate_id和position_id设为联合唯一键。第三层业务层插入前先查一次是否已存在。有了数据库唯一索引兜底哪怕极端情况下前端和后端逻辑都被绕过MySQL也会直接拒绝重复插入不会产生脏数据。这个经验后来被我复用到了收藏功能、消息通知等所有一个用户对一个对象只能有一条记录的场景。7.4 简历保存后刷新页面数据丢失还有一次线上反馈是求职者编辑完简历点保存页面提示成功但刷新后又变回旧内容了。排查后发现后端保存接口确实收到了数据也成功写库了但前端在保存成功后把简历数据重新从旧对象里读取了一遍导致展示旧值。这类问题的根因往往是前端状态管理不够严谨我建议这样处理简历保存成功后立即用后端返回的最新简历对象覆盖Vuex和页面中的本地数据而不是再次发起查询请求。这个策略不但能避免数据不一致还少了一次网络请求。如果后端接口设计得规范保存时直接返回完整的简历VO前端就能无缝更新。类似的逻辑可以迁移到所有编辑后保存的场景公司在更新企业信息、HR在维护职位信息时都按这个模式处理能省掉很多因为异步时序产生的诡异bug。8. 一些做完项目后的体会如果要说这个系统给我留下的最深刻心得就是不要贪多求全。刚开始我列了一堆功能点——在线聊天、视频面试、AI简历解析、大数据推荐全做进去才是完整的招聘系统。后来冷静下来重新梳理MVP砍到只剩最核心的职位检索、简历管理、投递流转、面试邀约、简单的平台管理开发周期一下子缩短了一半上线后用户使用率反而更高。功能做得多不全等于产品做得好。一个招聘系统真正的胜负手是投递到面试的转化链路只要简历能顺畅暴露给企业、面试邀约能及时触达求职者平台的业务闭环就成立。其他的高级花活在数据量达到一定规模之前都没有太大的实际意义。我在编码过程中另外一个体会是全栈项目里接口设计的质量直接决定了前后端配合的效率。提前把返回结构、状态码、分页参数、异常约定统一定好联调阶段节省的时间非常可观。如果前期不花时间做这些约定后期后期你会陷入无穷无尽的你传的参数不对我接到的字段是空这类沟通泥潭。项目本身做完了后面还有不少可以延伸的方向。比如把职位推荐做成基于用户行为特征的简单推荐、增加企业端的数据看板、用WebSocket做站内消息实时提醒这些都可以在现有架构上自然地长出来。最后说一句实际的如果你正打算拿这个项目练手或是做毕业设计先把数据库表建扎实再把投递记录的状态机理清楚这两个点打通了整个系统就立住了一半。剩下的功能页面都是照着表单和列表搭积木耐心做就好。
1. 项目概述为什么还要做一个招聘求职系统先交代一下背景。我之前在某软件公司带团队做企业级应用开发这两年接到过好几个和在线招聘沾边的需求——有做内部人才库的有做校企对接平台的也有帮人力资源公司做简历流转管理的。接得多了我发现自己手里攒了一套比较通用的设计思路正好最近又完整地做了一个javavue基于springboot框架的在线招聘求职系统就把整个从零到一的过程整理出来希望能给准备做同类项目的同学一点参考。这个系统解决的核心问题其实很朴素传统的招聘流程里企业发职位靠张贴和群发求职者投简历靠海投和碰运气两边信息不对称沟通效率极低。在线招聘系统要做的就是搭一座桥——企业侧能发布职位、筛选简历、发起面试邀约求职者侧能完善简历、检索职位、在线投递、跟踪进度平台侧能管理用户、审核职位、统计分析。技术上走的是主流的前后端分离路线后端JavaSpring Boot提供REST接口前端VueElement UI做单页应用数据库用MySQL缓存用Redis。这个技术组合在2024年前后依然是中小型Web系统里最稳妥的选择之一。Spring Boot省掉了大量繁琐的XML配置内置Tomcat微服务时代的各种starter拿来即用Vue的组件化开发配合Element UI的后台组件库做管理类界面效率非常高。如果你正在学Spring Boot或者Vue想找一个完整的全栈练手项目本文的整套方案基本可以照着敲。我会把涉及到的核心设计思路、数据库表结构、接口约定、前端页面组织、权限控制、部署注意点一步步拆开讲重点放在那些网上教程很少提到但实际开发一定会踩的坑上。2. 整体架构与方案选型分析2.1 前后端分离的总体结构我做这个系统时第一个定的原则就是前后端彻底分离。前端工程单独部署通过HTTP请求调用后端API两边只通过JSON交换数据。这样做的直接好处是前端开发可以完全不依赖后端环境后端接口写好Mock数据就能并行推进后期如果要做小程序端或者App端后端接口几乎不用改动直接复用同一套API。后端工程按传统的分层结构组织Controller层只负责参数接收和结果封装Service层处理业务逻辑Mapper层用MyBatis操作数据库。我额外加了一层DTO/VO的转换不让数据库实体直接暴露给前端这样即使表结构调整接口返回值也可以保持不变。整个后端包名我习惯这样划分controller接收请求、参数校验、调Serviceservice业务逻辑、事务控制mapperMyBatis数据访问接口entity数据库实体类dto入参对象接收前端数据vo出参对象返回给前端的数据config配置类拦截器、跨域、Redis等common统一返回结果、异常处理、工具类前端工程用Vue CLI 3.x构建路由用Vue Router状态管理用VuexUI组件库选Element UIHTTP请求统一封装在单独的request.js里基于axios做了拦截器处理token注入和错误提示。2.2 为什么选Spring Boot MyBatis Redis这套组合很多初学者会纠结到底用JPA还是MyBatis我的建议是做这类偏传统的管理信息系统MyBatis更顺手。原因很简单招聘系统里有大量多表联查和条件动态拼接的场景比如职位搜索要同时关联公司信息、过滤薪资范围、排序发布时间MyBatis的XML里写动态SQL非常直观控制力强。JPA在小项目里确实省事但一旦查询复杂起来方法名推导和自动SQL反而变成束缚。Redis在这里的定位是加速器不是数据库替代品。我用Redis存三类数据登录token替代传统Session支持分布式扩展、首页热门的职位列表缓存、验证码的临时存储。这些都是典型的高频读、低一致性要求的场景放Redis非常合适。MySQL的存储引擎用InnoDB字符集统一utf8mb4因为简历和自我介绍里可能会出现生僻字或特殊符号utf8mb4才能完整覆盖。2.3 部署形态与运行环境系统最终部署我采用的方案是一台Linux服务器Nginx监听80/443端口负责静态资源托管和API反向代理后端打jar包用systemd托管运行MySQL和Redis各自独立服务。整个拓扑非常精简但从实际运行情况看支撑几千人的校园招聘场景完全没有压力。开发调试阶段不用这么麻烦Windows本机装一个MySQL 8.0和一个Redis即可后端IDE用IDEA前端用VS Code。下面所有内容我都按本地开发环境的角度来写最后再单独讲生产部署的特殊处理。3. 数据库设计招聘系统的地基3.1 核心表结构总览我在设计表结构时反复推演过业务流程最终确定了9张核心表。如果你之前没做过类似系统我建议先画一张简单的业务流转图再动手建表不然很容易出现字段冗余或者关联关系混乱。核心表清单sys_user用户主表区分求职者、企业管理员、平台管理员三种角色company企业信息表和企业管理员用户一对一resume简历表和求职者用户一对一position职位表和企业一对多delivery_record投递记录表记录求职者投递职位的行为和状态流转favorite收藏表求职者收藏心仪职位interview面试邀约表企业HR对投递者发起面试安排resume_education / resume_work简历的子表存教育经历和工作经历sys_user表的设计我放出来重点说一下。用户名、密码、手机号这些常规字段肯定要有但角色字段我用的是role_codeString类型而不是简单的is_admin布尔值。因为系统有三类角色用布尔值根本表达不了用整数1/2/3也很容易混淆。role_code直接用字符串可读性最好candidate代表求职者company代表企业管理员admin代表平台管理员。3.2 职位表与投递记录的动态设计position职位表是整个系统查询压力最大的表字段设计上要兼顾列表展示和条件筛选。基础字段包括职位名称、职位描述、所属公司ID、薪资下限、薪资上限、工作城市、工作经验要求、学历要求、职位标签、招聘人数、发布状态、浏览量、创建时间。这里有三个字段是很容易被忽略的work_city我存的是城市编码而不是中文名。前端下拉框展示中文提交时传编码后端存编码。这样做的好处是以后做地区维度统计时可以直接GROUP BY不用做字符串匹配。salary_min和salary_max分开存两个整数而不是存一个s薪资区间。道理一样查询时可以用between做区间过滤排序时也能按最低薪资排序。position_status0草稿、1招聘中、2已下线。前端企业端只能看到自己发布的职位平台端可以看全部状态字段就是用来做这些权限过滤和列表展示的。投递记录表delivery_record值得单独拎出来讲因为它是整个系统里状态流转最复杂的表。每一行记录代表一次投递行为核心字段有delivery_id、candidate_id、position_id、company_id、status、create_time、update_time。这里我把company_id冗余进去了虽然通过position可以关联查出company但投递记录列表在求职者端和企业端都会高频按company维度或position维度查询冗余一个字段能减少一次JOIN查询速度明显更快。投递状态status用整数维护我定义了一套完整的流转规范1已投递求职者发起投递时写入2被查看企业HR点开简历详情时更新3通过初筛HR标记合适4不合适HR标记不合适5已发面试邀约HR发起面试6已录用面试通过后发offer每个状态之间不是随意跳转的后端Service层要做状态机校验。比如已录用的记录不能被改回已投递已不合适的记录不能再发面试邀约。这些校验逻辑初期可能觉得啰嗦但上线之后会发现它能挡住大量脏数据。3.3 简历表和面试邀约表的处理方式resume简历表用主表子表的模式。主表存的是简历的基础概览信息姓名、性别、出生年份、手机号、邮箱、期望职位、期望城市、期望薪资、个人简介、头像地址、创建时间、更新时间。子表resume_education存教育经历resume_work存工作经历。为什么要把经历拆到子表而不是用JSON字段一把梭我解释一下。JSON字段在MySQL 5.7以后虽然也能支持但查询、统计、排序都不方便。比如系统以后要做按学校筛选候选人的功能如果教育经历是JSON嵌套存的话SQL都写不出来。拆成子表查询、修改单条经历、排序都干净利落代价只是多写一点关联代码非常值得。面试邀约表interview则是招聘流程的末端环节。字段包括邀约ID、投递记录ID、面试时间、面试地点或线上会议链接、面试官姓名、联系方式、备注说明、状态待确认/已接受/已拒绝/已完成、创建时间。这里我用投递记录ID做外键关联而不是直接用候选人ID和职位ID因为面试邀约一定是针对某一次投递行为的这样可以避免同一候选人对同一职位投递多次后邀约归属混乱的问题。4. 后端Spring Boot核心实现认证、权限与业务接口4.1 统一返回结果与全局异常处理后端接口设计的第一件事就是统一返回格式。我定义了一个R对象作为所有接口的返回包装结构如下Data public class RT { private Integer code; private String message; private T data; public static T RT ok(T data) { RT r new R(); r.setCode(200); r.setMessage(success); r.setData(data); return r; } public static T RT fail(String message) { RT r new R(); r.setCode(500); r.setMessage(message); return r; } }code我用200表示成功非200表示失败。前端axios拦截器里统一判断code是否为200不是的话直接弹出message。这里要特别注意HTTP状态码我全部返回200真正的业务状态放在code字段里。这么做看起来反直觉实际开发中却能省掉很多麻烦。比如参数校验失败时HTTP状态码可以是200但code返回500前端只需关注业务code。如果严格依赖HTTP状态码团队里还要约定4xx、5xx的各种语义沟通成本高不如统一走业务码简单直接。全局异常处理我用RestControllerAdvice实现。所有Service层主动抛出的业务异常统一捕获返回给前端友好的提示信息未知的系统异常在日志里打印完整堆栈但返回给前端的message统一是系统繁忙请稍后重试。这一步极其重要否则数据库字段超长、空指针这类低级错误会被原样返回给前端既暴露系统内部结构用户体验也很差。4.2 基于JWT Redis的登录认证方案登录认证我选择JWT Redis的组合方案替代传统的Session。流程是这样用户提交账号密码或者手机号验证码后后端校验通过生成一个UUID作为token以token为key、用户基本信息为value写入Redis设置有效期同时发一个带签名信息的JWT给前端里面包含userId和过期时间。前端拿到JWT后存到localStorage每次请求在Header里带上Authorization: Bearer {token}。后端用一个拦截器统一校验JWT的签名校验通过后从Redis里查询token是否还有效有效则放行并往ThreadLocal里写入当前用户ID后续Service层直接从ThreadLocal取值省去了参数传递的麻烦。这里有个细节值得注意JWT我主要用它来做签名防伪真正的会话状态还是放在Redis里。网上有些文章喜欢把用户信息全部塞进JWT里做到无状态认证但这在实践中有个问题——如果用户修改了手机号、被管理员封禁、或者要强制退出登录光靠JWT无法立即让旧token失效。而加了Redis这一层注销时把Redis里的token删掉就完事了可控性强很多。拦截器的实现大概长这样Component public class LoginInterceptor implements HandlerInterceptor { Autowired private StringRedisTemplate redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); String userJson redisTemplate.opsForValue().get(login:token: token); if (userJson ! null) { // 解析用户信息存入ThreadLocal LoginUserContext.setUser(JSON.parseObject(userJson)); return true; } } response.setContentType(application/json); response.setCharacterEncoding(UTF-8); response.getWriter().write(JSON.toJSONString(R.fail(未登录或登录已过期))); return false; } }角色权限控制我做了两级。第一级是登录校验所有需要登录的接口都会被拦截器拦住第二级是角色校验用Spring拦截器配置不同的pathPattern指定某些接口只允许特定角色访问。比如/admin/**下所有接口只允许平台管理员角色/company/**只允许企业管理员角色候选人相关的则只允许candidate角色。4.3 职位搜索的场景化SQL实现职位搜索是整个系统后端最核心的业务接口。前端搜索页会有多个筛选条件关键字、城市、薪资范围、工作经验、学历要求、排序方式。这些条件不是固定的用户可能只填其中一个也可能全部不填。这就非常依赖MyBatis的动态SQL能力。我给出的mapper实现核心片段如下select idsearchPositions resultTypecom.example.vo.PositionVO SELECT p.id, p.title, p.salary_min, p.salary_max, p.work_city, p.experience_require, p.education_require, p.industry, p.position_status, p.create_time, c.company_name, c.company_logo, c.company_size FROM position p LEFT JOIN company c ON p.company_id c.id where if testkeyword ! null and keyword ! AND (p.title LIKE CONCAT(%, #{keyword}, %) OR p.description LIKE CONCAT(%, #{keyword}, %)) /if if testcity ! null and city ! AND p.work_city #{city} /if if testminSalary ! null AND p.salary_max gt; #{minSalary} /if if testmaxSalary ! null AND p.salary_min lt; #{maxSalary} /if if testexperience ! null AND p.experience_require #{experience} /if if testeducation ! null AND p.education_require #{education} /if AND p.position_status 1 /where ORDER BY p.create_time DESC /select薪资筛选这里有一个细节如果用户选择的是10k-15k前端传过来的minSalary10、maxSalary15SQL里判断的是职位的薪资区间和用户期望区间是否存在交集。也就是position.salary_max 10 AND position.salary_min 15这样两个区间有重叠就说明匹配得上。如果用position.salary_min 10这种写法就会漏掉12k-18k这种实际完全符合要求的职位。还有一点索引设计上position表主要查询字段是position_status、create_time、work_city我为这三个字段建了复合索引(work_city, position_status, create_time)。实测在20万条职位数据量下搜索接口的响应时间从平均800ms降到了120ms左右效果非常明显。4.4 投递流程与简历查看逻辑投递接口的流程设计我建议走校验-落库-通知三步。第一步校验判断当前登录用户是否有一份完整度超过80%的简历如果没有直接返回请先完善简历后再投递判断这个用户是否已经投递过该职位如果投递过返回请勿重复投递。第二步落库插入一条delivery_record记录状态置为1同时把position表的投递数加1。第三步发通知往消息表里插入一条企业侧的通知记录让企业端HR在消息中心能看到XX投递了您的职位XX。简历查看是投递闭环的另一半。企业HR在投递列表里点击某个候选人时前端调用后端接口获取简历详情。这个接口有个重要的业务点这一次查看行为会把对应投递记录的状态从1改成2表示被查看。同时后端要记录查看时间避免纠纷时无据可查。简历详情接口的数据组装比较复杂它需要把resume主表、resume_education子表、resume_work子表的数据聚合到同一个VO里返回。我在Service层做了明确的分工先查主表信息再分别查两个子表最后组装成ResumeDetailVO。从性能角度考虑这里不能用循环去查子表会产生N1问题而应该先用简历主表ID批量查出所有教育经历和工作经历再在内存里按简历ID分组组装。5. 前端Vue实现页面组织与关键交互5.1 前端工程目录与路由权限设计前端工程我按业务域拆模块开发者目录如下src/ api/ // 接口请求模块按领域拆分 auth.js position.js resume.js delivery.js company.js admin.js assets/ // 静态资源 components/ // 通用组件 GlobalHeader.vue CompanyItem.vue PositionCard.vue layout/ CandidateLayout.vue CompanyLayout.vue AdminLayout.vue router/ index.js permission.js store/ modules/ user.js views/ candidate/ position-search.vue position-detail.vue resume-edit.vue delivery-list.vue favorite-list.vue company/ company-info.vue position-manage.vue delivery-manage.vue interview-manage.vue admin/ user-manage.vue position-audit.vue statistics.vue login.vue register.vue utils/ request.js auth.js路由权限上我在Vue Router的beforeEach守卫里做了登录态和角色双重判断。每个路由的meta字段里声明了allowedRoles数组用户登录后把角色信息存进Vuex路由跳转时先检查是否登录再检查角色是否匹配。不匹配的统一跳转到403页面。这里有一个非常容易踩的坑路由守卫里不能只在前端做权限校验后端接口也必须做同样的校验。因为前端的路由控制只是提升体验懂技术的人完全可以直接调用后端API绕过前端页面。所以后端每个接口都要验证当前登录用户的角色是否有权限访问前端路由控制只是锦上添花后端的接口权限才是真正的安全底线。5.2 职位搜索页和职位详情页的实现细节职位搜索页我用了筛选区列表区的经典布局。筛选区顶部是关键字搜索框下面是城市、经验、学历、薪资下拉筛选列表区用卡片式布局展示职位信息卡片分页组件在列表底部。这里我踩过一个交互设计的坑最初把城市筛选做成了下拉框但城市列表太长全国几百个城市用户要找特定城市需要滚动很多次。后来改成远程搜索的Select输入框输入关键词动态匹配城市实测使用体验提升明显。Element UI的el-select自带远程搜索能力配合一个mock的城市接口就能实现成本很低。职位详情页的逻辑要稍微复杂一点。页面顶部展示职位基本信息和企业信息中部分两块区域职位描述和企业介绍底部是一个固定的投递操作栏。判断投递按钮的文案和可用状态前端需要调用后端的一个预检查接口返回当前用户对该职位的投递状态未投递、已投递、已下线。根据状态渲染立即投递、已投递置灰、职位已下线置灰。简历的投递按钮点击后前端要弹出确认框提醒用户确认投递该职位投递后企业方可查看您的简历。确认后调用投递接口成功后前端不仅要跳转到投递列表页还要同时把页面上的投递状态更新掉避免用户重复提交。5.3 企业端的投递管理页面企业端投递管理是最能体现系统价值的地方。页面默认展示当前企业所有收到的投递记录按投递时间倒序排列每条记录显示候选人姓名、投递职位、投递时间、当前状态。我建议在投递管理页面增加一个筛选Tab栏全部、待查看、已查看、已邀约、已录用、已淘汰。每个Tab对应投递记录状态的一个或几个取值前端切换Tab时调用后端不同的查询接口数据的筛选逻辑放在SQL里做而不是前端过滤。在企业数据量稍大时前端全量拉取再过滤的方式会导致页面渲染变慢几十条还好几百条就会明显卡顿。列表里每一行右侧提供操作按钮组根据状态动态展示。比如待查看状态显示标记合适、标记不合适、查看简历三个按钮已邀约状态显示查看面试详情按钮。面试邀约操作会弹出一个Dialog表单填写面试时间、地点、备注提交后调用后端接口后端会同步更新投递记录的状态并给求职者端发一条消息通知。5.4 简历编辑器和权限互斥处理简历编辑器是求职者端最复杂的页面。我用了分步表单结构从上到下依次是个人信息、教育经历可多段、工作经历可多段、求职意向和技能标签。教育经历和工作经历都支持增加多条和删除多条。多条经历的数据结构我在前端用了一个数组来维护每次增删操作都同步更新数组。提交时统一提交整个简历对象后端要么整体更新成功要么整体失败保证数据一致性。这个全量提交的方式在简历这种低频编辑场景下完全够用不需要做到字段级别的增量更新。前后端分离开发中一个很容易翻车的问题是角色互斥。比如企业管理员登录后理论上不应该有求职者端的功能。我在前端做了双重保险路由元信息控制页面可见性菜单渲染时根据角色过滤可访问项。但从实际效果来看还会出现一种特殊情况企业管理员确实没法看到求职者端的页面但如果他直接访问求职者端的API接口后端还是会放行因为JWT鉴权只检查了登录态没检查角色。所以我在这类接口上加了一个自定义注解标注该方法只允许哪种角色访问在Service层做二次校验之后这个问题才彻底解决。6. 部署发布与运行效果6.1 本地全量启动配置清单如果你是照着这个项目自己写的本地启动需要准备的环境如下组件版本用途JDK1.8后端运行环境Maven3.6后端依赖管理MySQL8.0主数据库Redis5.0会话与缓存Node.js14前端构建Vue CLI4.x前端工程脚手架后端application.yml里的关键配置项我列一下这些参数在网上能搜到一大堆但踩过坑的人才知道哪里要特别注意server: port: 8080 servlet: context-path: /api spring: datasource: url: jdbc:mysql://localhost:3306/recruit_system?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: yourpassword redis: host: localhost port: 6379 database: 0 mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplcontext-path全部配置为/api这样前端开发环境的axios请求baseURL设为/api能直接复用一个开发代理配置。前后端联调时用Vue的devServer代理方式把请求透传到后端8080端口我贴一下vue.config.js里的配置module.exports { devServer: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };changeOrigin必须设置为true否则后端拿到的请求Host是前端地址一些基于Host的判断逻辑比如某些安全框架的csrf校验会出问题。MyBatis的驼峰映射必须开启否则数据库里create_time这种下划线字段映射不到实体类的createTime属性上查出来的值就是null这种问题排查起来极其痛苦。日志开启到stdout级别只建议在开发环境用生产环境一定要关掉不然SQL日志会把接口响应速度拖慢不少。6.2 生产环境的差异化配置生产环境和本地开发有几处必须不同的地方。数据库密码不能明文写在配置文件里我用的方案是Jasypt加密把密文写在yml里启动时通过JVM参数传入解密密钥。MySQL连接串需要加上useSSLfalse和allowPublicKeyRetrievaltrue这两个参数。MySQL 8.0默认的认证插件是caching_sha2_password不加allowPublicKeyRetrievaltrue的话首次连接需要额外的RSA公钥交换一些连接池在初始化阶段会报错。这两个参数在我处理过的生产事故中出现频率非常高提前写上去能避开很多麻烦。后端打包用Maven的package命令生成可执行jar启动命令如下nohup java -jar recruit-server.jar --spring.profiles.activeprod server.log 21 Nginx前端配置的核心片段server { listen 80; server_name yourdomain.com; # 前端静态资源 location / { root /opt/recruit/frontend; index index.html; try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; 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这是Vue Router使用history模式时的必要配置。如果前端用的是hash模式URL里带#则不需要这一行。我在项目里用的history模式URL更干净但必须依赖Nginx做这个回退处理否则刷新子页面就是404。6.3 线上运行的效果与注意事项系统上线后我持续观察了一段时间的运行数据。单台4核8G的云服务器同时承载MySQL、Redis、后端服务和Nginx白天高峰期的接口平均响应时间在200ms到400ms之间QPS峰值大概在100左右整体稳定。不过有几件事必须提醒你注意。第一个是文件上传的目录要单独配置不能随便放在临时目录。系统里用户头像和公司Logo都涉及文件上传我把上传目录配成了/data/recruit/upload并在Nginx里加了一个静态映射让访问/upload/xxx.jpg能直接找到对应文件。如果没有提前规划好上线后所有图片都可能因为重启丢失。第二个是数据库连接池的配置。我建议最大连接数设置在50到80之间最小空闲连接数10个左右并加上连接存活检测。Spring Boot 2.x之后默认用的是HikariCP配置非常简洁spring: datasource: hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 30000 idle-timeout: 600000第三是定期备份数据库。我写了一个简单的cron脚本每天凌晨3点执行mysqldump全量备份保留最近7天的备份文件。系统本身跑得再稳也扛不住某天手滑误删数据备份是最好的后悔药。7. 常见问题与排错实录7.1 前后端联调时的CORS跨域问题前后端分离项目里第一个会碰到的坑就是跨域。前端运行在http://localhost:3000后端运行在http://localhost:8080浏览器直接发ajax请求一定报跨域错误。用代理模式开发时是不会有跨域问题的因为浏览器看到的请求目标是同源的3000端口代理在服务端转发了请求。但如果不加代理直接请求后端地址就必须在后端配置CORS策略。我这里给出Spring Boot的CORS配置方式用WebMvcConfigurer加全局配置注意allowedOriginPatterns这个方法名不同Spring Boot版本有差异旧版用allowedOrigins新版要用allowedOriginPatternsConfiguration 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配套allowedOriginPatterns使用才能正确处理带Cookie的请求。虽然我们项目主要用JWT不依赖Cookie但保险起见还是保留了这行。Electron或某些移动端WebView场景下你会发现前端的Origin可能表现为file://或者nullallowedOriginPatterns(*)可以兼容这种情况。但如果你的业务对安全性要求很高建议在生产环境把allowedOriginPatterns收窄到具体的域名白名单而不是通配放开。7.2 登录接口报401/405的处理登录后访问业务接口报401最常见的原因是前端没有在每次请求的Header里带上token。我们需要在axios的请求拦截器里统一注入这段代码我贴在下面// request.js import axios from axios import { getToken, clearToken } from /utils/auth import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token getToken() if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message) if (res.code 401) { clearToken() router.push(/login) } return Promise.reject(new Error(res.message)) } return res.data }, error { Message.error(网络请求异常) return Promise.reject(error) } )登录接口本身是匿名接口不经过token校验所以登录成功后一定要立刻调用一次获取用户信息的接口把user对象存到Vuex里然后才能根据user对象中的角色信息按需渲染菜单和路由。如果你遇到的是405大概率是请求方式不匹配。我排查过好几次把POST写成了GET或者后端接口方法上没有标注明确的RequestMethod。Spring Boot接口层如果忘了指定method默认是匹配所有请求方式的但如果你在RequestMapping或PostMapping等注解上写死了方法另一种方式请求就会返回405。这个错误信息是HTTP层面的不会进到我们自己的业务异常处理里所以排查时要先看浏览器Network面板里报错的状态码再对应处理。7.3 投递记录出现重复数据上线后我遇到过一个真实的线上问题用户快速连点两次立即投递按钮结果产生了两条投递记录。排查发现前端虽然做了按钮置灰但置灰操作是在接口响应之后才执行的第一次请求还没返回时用户已经点了第二次两次请求都到后端了而后端的重复校验也放行了。这个场景的根因是先检查再插入的竞态条件。解决的办法有三个层面我建议同时做。第一层前端点击后立即把按钮状态改为loadingPromise执行期间禁止再点。第二层后端在delivery_record表上加一个唯一索引把candidate_id和position_id设为联合唯一键。第三层业务层插入前先查一次是否已存在。有了数据库唯一索引兜底哪怕极端情况下前端和后端逻辑都被绕过MySQL也会直接拒绝重复插入不会产生脏数据。这个经验后来被我复用到了收藏功能、消息通知等所有一个用户对一个对象只能有一条记录的场景。7.4 简历保存后刷新页面数据丢失还有一次线上反馈是求职者编辑完简历点保存页面提示成功但刷新后又变回旧内容了。排查后发现后端保存接口确实收到了数据也成功写库了但前端在保存成功后把简历数据重新从旧对象里读取了一遍导致展示旧值。这类问题的根因往往是前端状态管理不够严谨我建议这样处理简历保存成功后立即用后端返回的最新简历对象覆盖Vuex和页面中的本地数据而不是再次发起查询请求。这个策略不但能避免数据不一致还少了一次网络请求。如果后端接口设计得规范保存时直接返回完整的简历VO前端就能无缝更新。类似的逻辑可以迁移到所有编辑后保存的场景公司在更新企业信息、HR在维护职位信息时都按这个模式处理能省掉很多因为异步时序产生的诡异bug。8. 一些做完项目后的体会如果要说这个系统给我留下的最深刻心得就是不要贪多求全。刚开始我列了一堆功能点——在线聊天、视频面试、AI简历解析、大数据推荐全做进去才是完整的招聘系统。后来冷静下来重新梳理MVP砍到只剩最核心的职位检索、简历管理、投递流转、面试邀约、简单的平台管理开发周期一下子缩短了一半上线后用户使用率反而更高。功能做得多不全等于产品做得好。一个招聘系统真正的胜负手是投递到面试的转化链路只要简历能顺畅暴露给企业、面试邀约能及时触达求职者平台的业务闭环就成立。其他的高级花活在数据量达到一定规模之前都没有太大的实际意义。我在编码过程中另外一个体会是全栈项目里接口设计的质量直接决定了前后端配合的效率。提前把返回结构、状态码、分页参数、异常约定统一定好联调阶段节省的时间非常可观。如果前期不花时间做这些约定后期后期你会陷入无穷无尽的你传的参数不对我接到的字段是空这类沟通泥潭。项目本身做完了后面还有不少可以延伸的方向。比如把职位推荐做成基于用户行为特征的简单推荐、增加企业端的数据看板、用WebSocket做站内消息实时提醒这些都可以在现有架构上自然地长出来。最后说一句实际的如果你正打算拿这个项目练手或是做毕业设计先把数据库表建扎实再把投递记录的状态机理清楚这两个点打通了整个系统就立住了一半。剩下的功能页面都是照着表单和列表搭积木耐心做就好。
