尧图网站建设 
人才招聘管理系统这个选题我前前后后带人做过三遍。第一遍完全是拍脑袋写职位表、简历表、候选人表堆完就开干第二遍换了一家正在快速招人的公司才发现原来“招聘管理”的核心根本不在数据库长得漂不漂亮而在于让HR、面试官、部门主管这三类人对待同一个候选人的进度保持一致。到第三遍再动手时我才真正体会到从零到一开发一套人才招聘管理系统最难的不是写代码而是把业务先拆清楚、把边界划明白然后再把“简历—投递—筛选—面试—Offer”这条链路用系统语言表达出来。这套系统解决的实际问题非常具体职位JD不再靠微信群发简历不再躺在HR的私人邮箱里候选人进入第几轮面试不需要靠口头沟通Offer审批结果不需要来回截屏。它本质上是一套企业内部使用的业务管理系统。适合正在练习全栈开发的新人照着完整做一遍也适合团队内部还没有ATS系统时由两三个人快速搭一版可用后台。如果你也准备动手建议你跟着我下面的思路走每一步背后我都会尽量讲清楚“为什么这么设计”。这篇文章覆盖了需求拆解、技术选型、数据库建模、后端接口、前端页面、联调部署和问题排查你可以把它当成一份完整的开发笔记来看。1. 项目需要管什么先把招聘流程拆开1.1 招聘系统到底解决了谁的痛点很多没有实际做过企业内部系统的人容易把“招聘管理系统”想成一个简历数据库以为就是把收到的简历存起来、能按关键词搜索就行。但真正到业务现场一看你会发现痛点根本不是“存不下来”而是信息在流转过程中散掉了。一个典型的招聘流程是这样跑的用人部门提出需求HR在各大渠道发布职位收到的简历分散在招聘网站后台、企业邮箱、微信聊天记录里。HR把觉得合适的简历下载下来可能在Excel里建了个表也可能没有。约面之后一面面试官看完给个口头反馈二面面试官未必能看到一面的记录候选人如果同时投了多个岗位状态就更容易乱。所以这套系统真正要解决的是“候选人这件事现在跑到哪个环节了”。每一位候选人、每一个投递记录都应该有一个清晰的状态并且这些状态要和真实的招聘动作一一对应比如“简历已筛选”“一面通过”“待二面”。当HR打开后台只靠一张候选人列表就能知道今天该跟进谁面试官收到反馈任务时能看到前一轮面试的评价和简历原文。这套系统的价值也体现在这里它是给招聘流程提供“记忆”的。一个人有没有来面试过、面试表现如何、为什么最后没通过全部沉淀在系统里。后续就算负责的HR离职新接手的人打开系统也能继续推进不会把候选人弄丢。1.2 核心角色与最小功能闭环人才招聘管理系统里的角色不需要做太多第一版我建议只保留三类账号管理员、HR、面试官。管理员负责账号分配和基础数据维护比如维护部门结构、用户权限开关。HR是系统的核心使用者他们建职位、上传简历、把候选人推荐到具体岗位、安排面试、录入面试结果。面试官的角色相对简单登录之后看到分配给我的面试任务查看候选人简历和之前轮次反馈填写本次评价和结论。围绕这三个角色第一版的业务闭环就是四件事建职位、收简历、约面试、发Offer。四件事串起来就是一组核心页面职位管理页、候选人管理页、面试安排页、Offer记录页。页面之外再配一个直观的统计看板展示在招职位数、本月新增简历数、待处理面试数、Offer通过率这些指标基本就是一个能实际跑起来的人才招聘管理系统了。我强烈建议第一版不要加“应聘者自助投递门户”。原因不是技术做不到而是业务上多一个面向外部用户的投递入口就要考虑注册、验证码、防刷、简历格式兼容、多渠道归集等一堆事情这些对MVP阶段完全是干扰。系统先服务好HR和面试官简历统一由HR录入并导入等内部跑顺了再考虑做对外收件箱和候选人门户。1.3 MVP范围哪些功能第一时间不做做这类管理系统最大的灾难是需求越做越多。比如有人会提出要做合同管理、入职办理、试用期转正甚至还要对接招聘平台自动同步简历。这些功能不是没有价值而是它们不属于“从零到一”的第一版闭环。我在动手之前给项目划过三条红线。第一不做复杂的审批流。一个Offer要不要走三层审批、部门负责人和HR负责人各自能不能改薪资范围这些东西在第一个版本里用一个“Offer状态字段”代替等业务量大了再单独上工作流引擎。第二不做自动化的招聘渠道同步。对接主流招聘平台需要开放接口权限和商业合作不是自己靠爬虫能稳定解决的问题。第一版里把“简历来源”做成下拉框选项就够了HR下载简历后手动录进来。第三不做简历文件的内容解析。这里说的解析是指从PDF或Word简历里自动抽取姓名、电话、工作经历。技术上有可行性但简历版式千奇百怪规则解析的准确率很难一上来就保证出错反而让HR不信任系统。第一版的做法是保存原始简历文件同时把“候选人姓名、手机、邮箱、工作年限、当前公司”等核心字段做成一页表单由HR自己录入。把这三个方向砍掉之后系统的边界就非常清晰了。代码量和业务逻辑都在可控范围内一个新开发经过两周密集投入完全可以交付一个能上线给HR试用的版本。2. 技术选型与工程初始化这套组合怎么定下来的2.1 后端框架为什么我推荐Spring Boot后端技术栈我选择的是Java 17 Spring Boot 3.x MyBatis-Plus MySQL 8。很多初学者会有疑问现在Python、Node.js、Go都挺火为什么推荐用Java这种“重一点”的方案答案很简单招聘管理系统在企业里通常不是孤立项目它后面很可能要对接公司的组织架构、权限中心、消息平台。Java生态里这些东西都有非常成熟的方案Spring Boot本身把数据库访问、事务管理、参数校验、异常处理整合得比较完整出问题后网上能查到的经验也远远多于小众框架。对开发新人来说用Spring Boot做这套系统学的沉淀是可迁移的——今天你做招聘系统明天做审批系统、客户管理系统底层的工程结构几乎是同一套。MyBatis-Plus我一般建议搭配使用它解决的是单表CRUD的样板代码问题。候选人表、职位表、面试表这种基础增删改查如果手写JDBC或者手写大量XML既枯燥又容易出低级错误。MyBatis-Plus提供BaseMapper单表操作可以不用写SQL业务查询再自己写XML或注解SQL效率和可控性之间有一个比较好的平衡。数据库选MySQL 8没有悬念唯一需要提醒的是建库时字符集要直接指定utf8mb4排序规则用utf8mb4_general_ci或者utf8mb4_0900_ai_ci都可以。招聘系统里候选人的姓名可能是中文、少数民族文字甚至包含少量生僻字和表情符号utf8mb4是底线。2.2 前端方案为什么是Vue3 Element Plus前端我没有选择重型的后台管理框架而是用了Vue 3 Vite Element Plus Vue Router Pinia这套组合。招聘管理系统的后台页面形态非常标准左侧菜单、顶部用户信息、中间内容区页面内以表格、表单、弹窗、日期选择器为主。Element Plus对这些组件的支持非常成熟特别是表格自带排序、筛选、分页表单自带校验规则消息弹窗、二次确认也都覆盖到了不需要前端团队投入大量时间造轮子。用Vite做构建工具主要是体验好。Vite冷启动快改动代码后热更新几乎没有等待感这在开发阶段对效率的提升非常明显。相比老一代的Webpack配置方式Vite的配置文件也更简短。Vue Router做路由跳转和菜单权限控制Pinia做用户登录信息和系统全局状态维护对这套系统来说已经足够了不需要引入特别复杂的全局状态管理方案。前后端通信统一走RESTful接口请求体用JSON。为了保持URL干净后端接口统一以/api开头前端开发服务器通过代理把/api转发到本地Spring Boot服务的8080端口。这样在后端做接口联调时就不用纠结跨域问题了等部署阶段再由Nginx统一处理静态资源转发和反向代理。2.3 初始化工程与目录规划工程结构我采用标准的前后端分离后端recruitment-server前端hr-admin。如果你打算从零复现建议和我保持一致。后端工程用Spring Initializr创建依赖选择Spring Web、Validation、MySQL Driver、Lombok然后手动在pom.xml里添加MyBatis-Plus和JWT相关依赖。包结构建议按业务模块划分而不是按技术层划分。com.example.recruitment ├── common // 统一响应、异常处理、常量 ├── config // 拦截器、跨域、上传配置 ├── controller // HTTP接口层 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 数据库表对应实体 ├── dto // 入参对象符合前端传参 └── vo // 返参对象面向页面展示前端工程创建比较简单一条命令就可以拉起来。npm create vitelatest hr-admin -- --template vue cd hr-admin npm install element-plus axios vue-router piniapages目录下先建四个一级页面Login.vue、Layout.vue、PositionList.vue、CandidateList.vue。后面做面试安排的时候再加一个InterviewList.vue就够。这里有一条项目初期的经验前后端字段命名必须提前统一。后端Java属性用驼峰命名数据库字段用下划线命名数据库字段通过MyBatis-Plus的map-underscore-to-camel-case自动转驼峰前端拿到JSON里的字段全部保持后端的驼峰命名。不要在接口返回字段上做一层“再转换”否则大量时间都会耗在这种纯手工字段映射上。3. 数据库表设计把招聘流程翻译成表结构3.1 核心表不只靠实体堆还要靠流程串数据库设计是这个系统的重要基础不能边写代码边想到哪建到哪。我在设计之前会先把业务中的名词拿出来梳理一遍用户、职位、部门、候选人、简历、投递记录、面试、Offer。这些名词要落成实体表但真正让它们跑起来的是“投递记录”和“面试”这种连接业务的关联表。这里特别提醒一个新手容易踩的坑候选人这张表上不要放“当前状态”字段。原因很直接同一个候选人完全可以同时投递A公司和B公司不是他在系统里可能同时投递市场岗和技术岗也可能同一天收到两个岗位的一面安排。如果把状态放在候选人表上这个候选人到底是“面试中”还是“已淘汰”就变成了一道无解题。正确的做法是把状态放到“投递记录表”上我们管它叫t_application。候选人是一个客观存在的人才他的基础属性放在候选人表里而候选人针对某个具体职位的招聘进展是“申请记录”的属性。候选人投A岗位是面试中投B岗位是已淘汰两种状态并行不悖。这个设计思路是整个系统的关键也是招聘系统区别于普通通讯录系统的关键。另一个关键设计是简历和候选人分离。候选人表存人的基础信息简历表存文件属性。为什么这么拆因为同一个人可能在未来某个时间再次投递简历那时他可能更新过工作经历简历文件和基础信息都会不同。把简历独立出来候选人每次投递就可以关联一份不同的简历文件系统也能保留历史版本不会出现新简历覆盖旧简历导致上一轮面试官看不到原始材料的情况。3.2 核心表字段设计与建表SQL实操下面给出最核心几张表的建表SQL。我这里统一使用下划线字段命名每张表都带上create_time和update_time这两个字段在问题排查时非常有用比如想知道一个候选人是哪一天被录进来的看时间字段比翻操作日志更方便。先看系统用户表。CREATE TABLE t_user ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(64) NOT NULL COMMENT 登录账号, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, real_name VARCHAR(64) NOT NULL COMMENT 真实姓名, role TINYINT NOT NULL DEFAULT 3 COMMENT 角色1-管理员2-HR3-面试官, email VARCHAR(128) DEFAULT NULL COMMENT 邮箱, phone VARCHAR(20) DEFAULT NULL COMMENT 手机号, 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT系统用户表;再来看职位表的建表语句。职位表中一个比较关键的字段是publish_status因为HR经常先把职位保存为草稿补齐JD后再对外发布。CREATE TABLE t_position ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 职位ID, position_code VARCHAR(64) NOT NULL COMMENT 职位编号内部使用, title VARCHAR(128) NOT NULL COMMENT 职位名称如Java开发工程师, department_id BIGINT NOT NULL COMMENT 所属部门ID, city VARCHAR(64) DEFAULT NULL COMMENT 工作城市, work_type TINYINT NOT NULL DEFAULT 1 COMMENT 1-全职2-实习3-兼职, min_salary INT DEFAULT NULL COMMENT 薪资下限单位K, max_salary INT DEFAULT NULL COMMENT 薪资上限单位K, headcount INT NOT NULL DEFAULT 1 COMMENT 招聘人数, publish_status TINYINT NOT NULL DEFAULT 0 COMMENT 0-草稿1-招聘中2-已关闭, description TEXT COMMENT 职位描述, creator_id BIGINT NOT NULL COMMENT 创建人ID, 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_position_code (position_code), KEY idx_position_status (publish_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT招聘职位表;候选人表和投递记录表是最能体现业务思考的。候选人表里放的是客观属性姓名、手机号、工作年限、当前公司、简历来源。注意不要放状态字段状态全部交给申请记录维护。CREATE TABLE t_candidate ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 候选人ID, name VARCHAR(64) NOT NULL COMMENT 姓名, mobile VARCHAR(20) NOT NULL COMMENT 手机号, email VARCHAR(128) DEFAULT NULL COMMENT 邮箱, gender TINYINT DEFAULT NULL COMMENT 1-男2-女, school VARCHAR(128) DEFAULT NULL COMMENT 毕业院校, education TINYINT DEFAULT NULL COMMENT 学历1-大专2-本科3-硕士4-博士, work_years INT DEFAULT NULL COMMENT 工作年限, current_company VARCHAR(128) DEFAULT NULL COMMENT 当前公司, source TINYINT NOT NULL DEFAULT 1 COMMENT 来源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), KEY idx_candidate_name_mobile (name, mobile) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT候选人表;投递记录表需要特别设置联合唯一约束避免同一个候选人重复投同一个职位。CREATE TABLE t_application ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 投递记录ID, candidate_id BIGINT NOT NULL COMMENT 候选人ID, position_id BIGINT NOT NULL COMMENT 职位ID, resume_id BIGINT DEFAULT NULL COMMENT 本次投递使用的简历ID, source TINYINT NOT NULL DEFAULT 1 COMMENT 投递来源, status TINYINT NOT NULL DEFAULT 1 COMMENT 流程状态1-待筛选2-筛选通过3-已淘汰4-面试中5-待Offer6-已入职, apply_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 投递时间, 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_candidate_position (candidate_id, position_id), KEY idx_application_position_status (position_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT候选人投递记录表;面试表是这个系统的“过程流水账”一个投递记录可能对应多轮面试用round字段标记第几轮。每次面试结束后由面试官更新feedback和result后续轮次的面试官就可以在候选人详情页看到前面的评价记录。CREATE TABLE t_interview ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 面试ID, application_id BIGINT NOT NULL COMMENT 投递记录ID, interviewer_id BIGINT NOT NULL COMMENT 面试官用户ID, round TINYINT NOT NULL DEFAULT 1 COMMENT 面试轮次1-一面2-二面3-HR面, interview_type TINYINT NOT NULL DEFAULT 1 COMMENT 1-现场2-视频, location VARCHAR(255) DEFAULT NULL COMMENT 现场面试地点或视频会议链接, interview_time DATETIME NOT NULL COMMENT 面试开始时间, feedback TEXT COMMENT 面试官评价, result TINYINT DEFAULT 0 COMMENT 0-待面试1-通过2-淘汰3-待定, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_interview_application (application_id), KEY idx_interview_interviewer_time (interviewer_id, interview_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT面试安排表;建表的时候有一个很容易忽略的经验业务表之间不要物理建立FOREIGN KEY外键约束。原因有三个第一招聘系统里经常要做逻辑删除和批量导入外键约束会影响导入顺序和灵活性第二将来如果做分库分表物理外键会成为障碍第三企业级应用更习惯在应用层保证数据完整性数据库只负责存储和基础约束。但“不建物理外键”不等于“不建索引”所有参与JOIN的字段比如candidate_id、position_id都必须建普通索引否则数据量上来之后查询会慢到无法接受。3.3 状态字段的取值和边界提前想清楚表设计完以后真正要花时间想的是状态机。int类型的status字段本身只是1、2、3这些数字但业务上它们之间的流转必须遵守规则。我的做法是在后端全局定义枚举常量或者常量类比如ApplicationStatusEnum里面写着PENDING_REVIEW1、SCREEN_PASS2、REJECTED3、INTERVIEWING4这样一组映射。代码里禁止出现魔法数字散落各处这样将来调整状态含义的时候只需要改一个地方。业务上需要明确的流转关系是待筛选可以转筛选通过也可以转已淘汰。筛选通过之后才能安排面试流程状态进入面试中。面试完成后如果通过且还有下一轮状态仍是面试中如果是最后一轮通过状态进入待Offer。任何已淘汰状态都不能由操作人自己随意拉回如果确实要重新启用应该走一个“重新激活”的逻辑。第一版里可以使用一个update接口做兜底但要记录操作人和原因。这里涉及的细节是面试的结果和投递的流程状态要区分开。每一轮面试有自己独立的result但整个申请的状态只有在关键时刻才向前推进。比如一面通过后申请记录还是“面试中”只有二面也通过并发起Offer审批时才由HR手动把申请状态置成“待Offer”。这个设计是为了避免后面出现问题排查时不知道候选人当前处于哪一个具体环节。4. 后端接口开发从简历上传到面试流转4.1 统一响应结构和登录接口后端我习惯先写一个统一响应类所有接口返回结构保持一致。响应体统一是{ code: 0, msg: success, data: ... }code为0表示成功非0表示业务异常。前端axios拦截器只要判断code不等于0就弹出错误提示代码会非常规整。登录接口按标准做法设计前端提交用户名和密码后端从t_user表查出用户用BCrypt算法校验密码。校验通过后生成一个TokenMVP阶段为了方便我使用的是JWT把用户ID和角色放进token里后续接口通过拦截器解析。实际开发时第一版也可以直接用Spring SessionRedis保存登录态但如果团队之前没引入Redis引入JWT反而更轻。JWT的缺点是服务端无法主动让token失效所以用户被禁用后需要等token过期才能生效。针对这一点系统解决方案是在拦截器里每次请求都检查用户状态如果t_user表里status等于0立即拒绝访问。这样一个被禁用的用户最多在改完状态后的第一次请求就被拦下来不会出现禁用无效的尴尬。简单写一下登录接口实现如果你用的也是Spring Boot基本结构差不多RestController RequestMapping(/api/auth) public class AuthController { Resource private UserService userService; PostMapping(/login) public ResultLoginVO login(RequestBody Valid LoginDTO dto) { // 1. 根据用户名查用户 User user userService.findByUsername(dto.getUsername()); if (user null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.fail(用户名或密码错误); } if (user.getStatus() ! 1) { return Result.fail(账号已被禁用请联系管理员); } // 2. 生成JWTexpire设置为12小时 String token JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok(new LoginVO(token, user.getRealName(), user.getRole())); } }这里有两个容易踩的点第一密码要用BCrypt加密不要用MD5因为MD5查表破解的成本太低第二JWT密钥不要硬编码在代码里放到application.yml配置文件中并且通过环境变量注入避免源码泄露导致token被伪造。4.2 简历上传与文件存储细节比想象多简历上传是整个系统中交互最频繁的接口之一。前端页面上HR点击上传按钮选择PDF或Word文件后端接口接收文件并保存。这里的实现要点不是controller里写三行代码把文件写盘而是围绕上传功能做四件细节处理。第一上传大小限制。Spring Boot默认单文件上传上限是1MB简历文件很容易超过这个值。在application.yml里必须显式设置spring: servlet: multipart: max-file-size: 20MB max-request-size: 20MB第二文件名处理。前端上传过来的原始文件名不能直接拼到服务器路径上否则可能遇到重名覆盖甚至路径穿越问题。我习惯把文件重命名为UUID加原扩展名另起一个新文件名原始文件名只作为展示字段存到数据库里。第三文件不能存到数据库BLOB字段里。简历文件可能存在几MB到十几MB不等如果直接存BLOB数据库体积会迅速变大备份恢复速度也会被拖慢。正确做法是把文件保存到服务器的指定目录下数据库只保存文件的相对路径和大小。第四文件保存目录必须使用绝对路径。这个问题我遇到过不少次项目在本地跑起来时相对路径没问题部署上线时如果启动命令所在目录和项目预期目录不一致文件就会传到未知位置。建议在application.yml里用一个自定义配置项recruitment: resume-storage-path: /opt/recruitment/uploads启动时判断目录不存在就自动创建。下面的示例代码综合处理了上面几点RestController RequestMapping(/api/resume) public class ResumeController { Value(${recruitment.resume-storage-path}) 人才招聘管理系统从零开发实战：业务边界与数据库设计全解析
人才招聘管理系统这个选题我前前后后带人做过三遍。第一遍完全是拍脑袋写职位表、简历表、候选人表堆完就开干第二遍换了一家正在快速招人的公司才发现原来“招聘管理”的核心根本不在数据库长得漂不漂亮而在于让HR、面试官、部门主管这三类人对待同一个候选人的进度保持一致。到第三遍再动手时我才真正体会到从零到一开发一套人才招聘管理系统最难的不是写代码而是把业务先拆清楚、把边界划明白然后再把“简历—投递—筛选—面试—Offer”这条链路用系统语言表达出来。这套系统解决的实际问题非常具体职位JD不再靠微信群发简历不再躺在HR的私人邮箱里候选人进入第几轮面试不需要靠口头沟通Offer审批结果不需要来回截屏。它本质上是一套企业内部使用的业务管理系统。适合正在练习全栈开发的新人照着完整做一遍也适合团队内部还没有ATS系统时由两三个人快速搭一版可用后台。如果你也准备动手建议你跟着我下面的思路走每一步背后我都会尽量讲清楚“为什么这么设计”。这篇文章覆盖了需求拆解、技术选型、数据库建模、后端接口、前端页面、联调部署和问题排查你可以把它当成一份完整的开发笔记来看。1. 项目需要管什么先把招聘流程拆开1.1 招聘系统到底解决了谁的痛点很多没有实际做过企业内部系统的人容易把“招聘管理系统”想成一个简历数据库以为就是把收到的简历存起来、能按关键词搜索就行。但真正到业务现场一看你会发现痛点根本不是“存不下来”而是信息在流转过程中散掉了。一个典型的招聘流程是这样跑的用人部门提出需求HR在各大渠道发布职位收到的简历分散在招聘网站后台、企业邮箱、微信聊天记录里。HR把觉得合适的简历下载下来可能在Excel里建了个表也可能没有。约面之后一面面试官看完给个口头反馈二面面试官未必能看到一面的记录候选人如果同时投了多个岗位状态就更容易乱。所以这套系统真正要解决的是“候选人这件事现在跑到哪个环节了”。每一位候选人、每一个投递记录都应该有一个清晰的状态并且这些状态要和真实的招聘动作一一对应比如“简历已筛选”“一面通过”“待二面”。当HR打开后台只靠一张候选人列表就能知道今天该跟进谁面试官收到反馈任务时能看到前一轮面试的评价和简历原文。这套系统的价值也体现在这里它是给招聘流程提供“记忆”的。一个人有没有来面试过、面试表现如何、为什么最后没通过全部沉淀在系统里。后续就算负责的HR离职新接手的人打开系统也能继续推进不会把候选人弄丢。1.2 核心角色与最小功能闭环人才招聘管理系统里的角色不需要做太多第一版我建议只保留三类账号管理员、HR、面试官。管理员负责账号分配和基础数据维护比如维护部门结构、用户权限开关。HR是系统的核心使用者他们建职位、上传简历、把候选人推荐到具体岗位、安排面试、录入面试结果。面试官的角色相对简单登录之后看到分配给我的面试任务查看候选人简历和之前轮次反馈填写本次评价和结论。围绕这三个角色第一版的业务闭环就是四件事建职位、收简历、约面试、发Offer。四件事串起来就是一组核心页面职位管理页、候选人管理页、面试安排页、Offer记录页。页面之外再配一个直观的统计看板展示在招职位数、本月新增简历数、待处理面试数、Offer通过率这些指标基本就是一个能实际跑起来的人才招聘管理系统了。我强烈建议第一版不要加“应聘者自助投递门户”。原因不是技术做不到而是业务上多一个面向外部用户的投递入口就要考虑注册、验证码、防刷、简历格式兼容、多渠道归集等一堆事情这些对MVP阶段完全是干扰。系统先服务好HR和面试官简历统一由HR录入并导入等内部跑顺了再考虑做对外收件箱和候选人门户。1.3 MVP范围哪些功能第一时间不做做这类管理系统最大的灾难是需求越做越多。比如有人会提出要做合同管理、入职办理、试用期转正甚至还要对接招聘平台自动同步简历。这些功能不是没有价值而是它们不属于“从零到一”的第一版闭环。我在动手之前给项目划过三条红线。第一不做复杂的审批流。一个Offer要不要走三层审批、部门负责人和HR负责人各自能不能改薪资范围这些东西在第一个版本里用一个“Offer状态字段”代替等业务量大了再单独上工作流引擎。第二不做自动化的招聘渠道同步。对接主流招聘平台需要开放接口权限和商业合作不是自己靠爬虫能稳定解决的问题。第一版里把“简历来源”做成下拉框选项就够了HR下载简历后手动录进来。第三不做简历文件的内容解析。这里说的解析是指从PDF或Word简历里自动抽取姓名、电话、工作经历。技术上有可行性但简历版式千奇百怪规则解析的准确率很难一上来就保证出错反而让HR不信任系统。第一版的做法是保存原始简历文件同时把“候选人姓名、手机、邮箱、工作年限、当前公司”等核心字段做成一页表单由HR自己录入。把这三个方向砍掉之后系统的边界就非常清晰了。代码量和业务逻辑都在可控范围内一个新开发经过两周密集投入完全可以交付一个能上线给HR试用的版本。2. 技术选型与工程初始化这套组合怎么定下来的2.1 后端框架为什么我推荐Spring Boot后端技术栈我选择的是Java 17 Spring Boot 3.x MyBatis-Plus MySQL 8。很多初学者会有疑问现在Python、Node.js、Go都挺火为什么推荐用Java这种“重一点”的方案答案很简单招聘管理系统在企业里通常不是孤立项目它后面很可能要对接公司的组织架构、权限中心、消息平台。Java生态里这些东西都有非常成熟的方案Spring Boot本身把数据库访问、事务管理、参数校验、异常处理整合得比较完整出问题后网上能查到的经验也远远多于小众框架。对开发新人来说用Spring Boot做这套系统学的沉淀是可迁移的——今天你做招聘系统明天做审批系统、客户管理系统底层的工程结构几乎是同一套。MyBatis-Plus我一般建议搭配使用它解决的是单表CRUD的样板代码问题。候选人表、职位表、面试表这种基础增删改查如果手写JDBC或者手写大量XML既枯燥又容易出低级错误。MyBatis-Plus提供BaseMapper单表操作可以不用写SQL业务查询再自己写XML或注解SQL效率和可控性之间有一个比较好的平衡。数据库选MySQL 8没有悬念唯一需要提醒的是建库时字符集要直接指定utf8mb4排序规则用utf8mb4_general_ci或者utf8mb4_0900_ai_ci都可以。招聘系统里候选人的姓名可能是中文、少数民族文字甚至包含少量生僻字和表情符号utf8mb4是底线。2.2 前端方案为什么是Vue3 Element Plus前端我没有选择重型的后台管理框架而是用了Vue 3 Vite Element Plus Vue Router Pinia这套组合。招聘管理系统的后台页面形态非常标准左侧菜单、顶部用户信息、中间内容区页面内以表格、表单、弹窗、日期选择器为主。Element Plus对这些组件的支持非常成熟特别是表格自带排序、筛选、分页表单自带校验规则消息弹窗、二次确认也都覆盖到了不需要前端团队投入大量时间造轮子。用Vite做构建工具主要是体验好。Vite冷启动快改动代码后热更新几乎没有等待感这在开发阶段对效率的提升非常明显。相比老一代的Webpack配置方式Vite的配置文件也更简短。Vue Router做路由跳转和菜单权限控制Pinia做用户登录信息和系统全局状态维护对这套系统来说已经足够了不需要引入特别复杂的全局状态管理方案。前后端通信统一走RESTful接口请求体用JSON。为了保持URL干净后端接口统一以/api开头前端开发服务器通过代理把/api转发到本地Spring Boot服务的8080端口。这样在后端做接口联调时就不用纠结跨域问题了等部署阶段再由Nginx统一处理静态资源转发和反向代理。2.3 初始化工程与目录规划工程结构我采用标准的前后端分离后端recruitment-server前端hr-admin。如果你打算从零复现建议和我保持一致。后端工程用Spring Initializr创建依赖选择Spring Web、Validation、MySQL Driver、Lombok然后手动在pom.xml里添加MyBatis-Plus和JWT相关依赖。包结构建议按业务模块划分而不是按技术层划分。com.example.recruitment ├── common // 统一响应、异常处理、常量 ├── config // 拦截器、跨域、上传配置 ├── controller // HTTP接口层 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 数据库表对应实体 ├── dto // 入参对象符合前端传参 └── vo // 返参对象面向页面展示前端工程创建比较简单一条命令就可以拉起来。npm create vitelatest hr-admin -- --template vue cd hr-admin npm install element-plus axios vue-router piniapages目录下先建四个一级页面Login.vue、Layout.vue、PositionList.vue、CandidateList.vue。后面做面试安排的时候再加一个InterviewList.vue就够。这里有一条项目初期的经验前后端字段命名必须提前统一。后端Java属性用驼峰命名数据库字段用下划线命名数据库字段通过MyBatis-Plus的map-underscore-to-camel-case自动转驼峰前端拿到JSON里的字段全部保持后端的驼峰命名。不要在接口返回字段上做一层“再转换”否则大量时间都会耗在这种纯手工字段映射上。3. 数据库表设计把招聘流程翻译成表结构3.1 核心表不只靠实体堆还要靠流程串数据库设计是这个系统的重要基础不能边写代码边想到哪建到哪。我在设计之前会先把业务中的名词拿出来梳理一遍用户、职位、部门、候选人、简历、投递记录、面试、Offer。这些名词要落成实体表但真正让它们跑起来的是“投递记录”和“面试”这种连接业务的关联表。这里特别提醒一个新手容易踩的坑候选人这张表上不要放“当前状态”字段。原因很直接同一个候选人完全可以同时投递A公司和B公司不是他在系统里可能同时投递市场岗和技术岗也可能同一天收到两个岗位的一面安排。如果把状态放在候选人表上这个候选人到底是“面试中”还是“已淘汰”就变成了一道无解题。正确的做法是把状态放到“投递记录表”上我们管它叫t_application。候选人是一个客观存在的人才他的基础属性放在候选人表里而候选人针对某个具体职位的招聘进展是“申请记录”的属性。候选人投A岗位是面试中投B岗位是已淘汰两种状态并行不悖。这个设计思路是整个系统的关键也是招聘系统区别于普通通讯录系统的关键。另一个关键设计是简历和候选人分离。候选人表存人的基础信息简历表存文件属性。为什么这么拆因为同一个人可能在未来某个时间再次投递简历那时他可能更新过工作经历简历文件和基础信息都会不同。把简历独立出来候选人每次投递就可以关联一份不同的简历文件系统也能保留历史版本不会出现新简历覆盖旧简历导致上一轮面试官看不到原始材料的情况。3.2 核心表字段设计与建表SQL实操下面给出最核心几张表的建表SQL。我这里统一使用下划线字段命名每张表都带上create_time和update_time这两个字段在问题排查时非常有用比如想知道一个候选人是哪一天被录进来的看时间字段比翻操作日志更方便。先看系统用户表。CREATE TABLE t_user ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(64) NOT NULL COMMENT 登录账号, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, real_name VARCHAR(64) NOT NULL COMMENT 真实姓名, role TINYINT NOT NULL DEFAULT 3 COMMENT 角色1-管理员2-HR3-面试官, email VARCHAR(128) DEFAULT NULL COMMENT 邮箱, phone VARCHAR(20) DEFAULT NULL COMMENT 手机号, 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT系统用户表;再来看职位表的建表语句。职位表中一个比较关键的字段是publish_status因为HR经常先把职位保存为草稿补齐JD后再对外发布。CREATE TABLE t_position ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 职位ID, position_code VARCHAR(64) NOT NULL COMMENT 职位编号内部使用, title VARCHAR(128) NOT NULL COMMENT 职位名称如Java开发工程师, department_id BIGINT NOT NULL COMMENT 所属部门ID, city VARCHAR(64) DEFAULT NULL COMMENT 工作城市, work_type TINYINT NOT NULL DEFAULT 1 COMMENT 1-全职2-实习3-兼职, min_salary INT DEFAULT NULL COMMENT 薪资下限单位K, max_salary INT DEFAULT NULL COMMENT 薪资上限单位K, headcount INT NOT NULL DEFAULT 1 COMMENT 招聘人数, publish_status TINYINT NOT NULL DEFAULT 0 COMMENT 0-草稿1-招聘中2-已关闭, description TEXT COMMENT 职位描述, creator_id BIGINT NOT NULL COMMENT 创建人ID, 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_position_code (position_code), KEY idx_position_status (publish_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT招聘职位表;候选人表和投递记录表是最能体现业务思考的。候选人表里放的是客观属性姓名、手机号、工作年限、当前公司、简历来源。注意不要放状态字段状态全部交给申请记录维护。CREATE TABLE t_candidate ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 候选人ID, name VARCHAR(64) NOT NULL COMMENT 姓名, mobile VARCHAR(20) NOT NULL COMMENT 手机号, email VARCHAR(128) DEFAULT NULL COMMENT 邮箱, gender TINYINT DEFAULT NULL COMMENT 1-男2-女, school VARCHAR(128) DEFAULT NULL COMMENT 毕业院校, education TINYINT DEFAULT NULL COMMENT 学历1-大专2-本科3-硕士4-博士, work_years INT DEFAULT NULL COMMENT 工作年限, current_company VARCHAR(128) DEFAULT NULL COMMENT 当前公司, source TINYINT NOT NULL DEFAULT 1 COMMENT 来源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), KEY idx_candidate_name_mobile (name, mobile) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT候选人表;投递记录表需要特别设置联合唯一约束避免同一个候选人重复投同一个职位。CREATE TABLE t_application ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 投递记录ID, candidate_id BIGINT NOT NULL COMMENT 候选人ID, position_id BIGINT NOT NULL COMMENT 职位ID, resume_id BIGINT DEFAULT NULL COMMENT 本次投递使用的简历ID, source TINYINT NOT NULL DEFAULT 1 COMMENT 投递来源, status TINYINT NOT NULL DEFAULT 1 COMMENT 流程状态1-待筛选2-筛选通过3-已淘汰4-面试中5-待Offer6-已入职, apply_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 投递时间, 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_candidate_position (candidate_id, position_id), KEY idx_application_position_status (position_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT候选人投递记录表;面试表是这个系统的“过程流水账”一个投递记录可能对应多轮面试用round字段标记第几轮。每次面试结束后由面试官更新feedback和result后续轮次的面试官就可以在候选人详情页看到前面的评价记录。CREATE TABLE t_interview ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 面试ID, application_id BIGINT NOT NULL COMMENT 投递记录ID, interviewer_id BIGINT NOT NULL COMMENT 面试官用户ID, round TINYINT NOT NULL DEFAULT 1 COMMENT 面试轮次1-一面2-二面3-HR面, interview_type TINYINT NOT NULL DEFAULT 1 COMMENT 1-现场2-视频, location VARCHAR(255) DEFAULT NULL COMMENT 现场面试地点或视频会议链接, interview_time DATETIME NOT NULL COMMENT 面试开始时间, feedback TEXT COMMENT 面试官评价, result TINYINT DEFAULT 0 COMMENT 0-待面试1-通过2-淘汰3-待定, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_interview_application (application_id), KEY idx_interview_interviewer_time (interviewer_id, interview_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT面试安排表;建表的时候有一个很容易忽略的经验业务表之间不要物理建立FOREIGN KEY外键约束。原因有三个第一招聘系统里经常要做逻辑删除和批量导入外键约束会影响导入顺序和灵活性第二将来如果做分库分表物理外键会成为障碍第三企业级应用更习惯在应用层保证数据完整性数据库只负责存储和基础约束。但“不建物理外键”不等于“不建索引”所有参与JOIN的字段比如candidate_id、position_id都必须建普通索引否则数据量上来之后查询会慢到无法接受。3.3 状态字段的取值和边界提前想清楚表设计完以后真正要花时间想的是状态机。int类型的status字段本身只是1、2、3这些数字但业务上它们之间的流转必须遵守规则。我的做法是在后端全局定义枚举常量或者常量类比如ApplicationStatusEnum里面写着PENDING_REVIEW1、SCREEN_PASS2、REJECTED3、INTERVIEWING4这样一组映射。代码里禁止出现魔法数字散落各处这样将来调整状态含义的时候只需要改一个地方。业务上需要明确的流转关系是待筛选可以转筛选通过也可以转已淘汰。筛选通过之后才能安排面试流程状态进入面试中。面试完成后如果通过且还有下一轮状态仍是面试中如果是最后一轮通过状态进入待Offer。任何已淘汰状态都不能由操作人自己随意拉回如果确实要重新启用应该走一个“重新激活”的逻辑。第一版里可以使用一个update接口做兜底但要记录操作人和原因。这里涉及的细节是面试的结果和投递的流程状态要区分开。每一轮面试有自己独立的result但整个申请的状态只有在关键时刻才向前推进。比如一面通过后申请记录还是“面试中”只有二面也通过并发起Offer审批时才由HR手动把申请状态置成“待Offer”。这个设计是为了避免后面出现问题排查时不知道候选人当前处于哪一个具体环节。4. 后端接口开发从简历上传到面试流转4.1 统一响应结构和登录接口后端我习惯先写一个统一响应类所有接口返回结构保持一致。响应体统一是{ code: 0, msg: success, data: ... }code为0表示成功非0表示业务异常。前端axios拦截器只要判断code不等于0就弹出错误提示代码会非常规整。登录接口按标准做法设计前端提交用户名和密码后端从t_user表查出用户用BCrypt算法校验密码。校验通过后生成一个TokenMVP阶段为了方便我使用的是JWT把用户ID和角色放进token里后续接口通过拦截器解析。实际开发时第一版也可以直接用Spring SessionRedis保存登录态但如果团队之前没引入Redis引入JWT反而更轻。JWT的缺点是服务端无法主动让token失效所以用户被禁用后需要等token过期才能生效。针对这一点系统解决方案是在拦截器里每次请求都检查用户状态如果t_user表里status等于0立即拒绝访问。这样一个被禁用的用户最多在改完状态后的第一次请求就被拦下来不会出现禁用无效的尴尬。简单写一下登录接口实现如果你用的也是Spring Boot基本结构差不多RestController RequestMapping(/api/auth) public class AuthController { Resource private UserService userService; PostMapping(/login) public ResultLoginVO login(RequestBody Valid LoginDTO dto) { // 1. 根据用户名查用户 User user userService.findByUsername(dto.getUsername()); if (user null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.fail(用户名或密码错误); } if (user.getStatus() ! 1) { return Result.fail(账号已被禁用请联系管理员); } // 2. 生成JWTexpire设置为12小时 String token JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok(new LoginVO(token, user.getRealName(), user.getRole())); } }这里有两个容易踩的点第一密码要用BCrypt加密不要用MD5因为MD5查表破解的成本太低第二JWT密钥不要硬编码在代码里放到application.yml配置文件中并且通过环境变量注入避免源码泄露导致token被伪造。4.2 简历上传与文件存储细节比想象多简历上传是整个系统中交互最频繁的接口之一。前端页面上HR点击上传按钮选择PDF或Word文件后端接口接收文件并保存。这里的实现要点不是controller里写三行代码把文件写盘而是围绕上传功能做四件细节处理。第一上传大小限制。Spring Boot默认单文件上传上限是1MB简历文件很容易超过这个值。在application.yml里必须显式设置spring: servlet: multipart: max-file-size: 20MB max-request-size: 20MB第二文件名处理。前端上传过来的原始文件名不能直接拼到服务器路径上否则可能遇到重名覆盖甚至路径穿越问题。我习惯把文件重命名为UUID加原扩展名另起一个新文件名原始文件名只作为展示字段存到数据库里。第三文件不能存到数据库BLOB字段里。简历文件可能存在几MB到十几MB不等如果直接存BLOB数据库体积会迅速变大备份恢复速度也会被拖慢。正确做法是把文件保存到服务器的指定目录下数据库只保存文件的相对路径和大小。第四文件保存目录必须使用绝对路径。这个问题我遇到过不少次项目在本地跑起来时相对路径没问题部署上线时如果启动命令所在目录和项目预期目录不一致文件就会传到未知位置。建议在application.yml里用一个自定义配置项recruitment: resume-storage-path: /opt/recruitment/uploads启动时判断目录不存在就自动创建。下面的示例代码综合处理了上面几点RestController RequestMapping(/api/resume) public class ResumeController { Value(${recruitment.resume-storage-path})