HR管理系统是一类很典型的业务系统，我这些年接过好几套类似的开发需求，规模有大有小，但核心逻辑惊人地一致：员工档案、考勤、请假、薪资、部门管理，再加上一套权限控制，基本就是全部。这套基于 Java + SpringBoot + SSM 的人力资源管理系统，就是围绕这些场景落地的一个完整方案，附带源码、文档、调试步骤和讲解材料，对于想从零学习 SSM 整合、准备毕业设计，或者说想给中小团队快速搭一套人事管理工具的开发者来说，都算得上是一份可以直接上手拆解的参考样本。

系统本身不做花哨的东西，就是把 HR 日常最头疼的那几件事——信息分散、流程靠人催、数据难统计——用一套 Web 应用串起来，让管理员、HR、普通员工各用各的入口，权限分明，流程留痕。这篇文章我不打算只讲“项目有什么”，而是把开发这套系统时最值得琢磨的模块设计、技术选型逻辑、数据库建模细节、核心代码实现和踩坑过程全部拆开讲清楚，你可以照着思路自己复现一版，也可以拿着这些细节去应对答辩或评审的追问。

1. 项目拆解：一套 HR 系统到底该装下什么

1.1 HR 日常的痛点，就是系统设计的出发点

我在实际接触这类需求时，发现一个很有意思的现象：绝大多数中小公司并不是不想用专业人事软件，而是觉得那些商业系统的功能太重、价格也不友好，最后又回到 Excel 加纸质审批的老路上。结果就是员工花名册散落在好几个人的电脑里，请假条在领导办公桌上躺了三天没人批，月底统计考勤和薪资纯靠人工对着记录一条条核算，效率低不说，还容易出岔子。这套系统解决的核心问题，其实就是信息统一管理和流程线上化。

从使用者的视角来看，系统里至少要出现三类角色。老板和 HR 希望能看到全局数据，比如各部门人数、当月请假情况、薪资发放记录；普通员工希望能够提交请假申请、查看自己的考勤和工资条；系统管理员则关心账号、权限、菜单和基础数据维护。三类角色的诉求叠加在一起，就决定了功能模块的边界，系统必须同时满足“管人”、“管事”和“控权限”三个层面的需要。

1.2 六大功能模块的职责切分

很多人一上来就想把系统做得很庞大，招聘、培训、绩效、社保全塞进去，结果每个模块都做得浅尝辄止，反而把核心功能拖垮了。这套系统的模块划分是经过取舍的，只保留了 HR 管理中最刚性、最高频的六个部分：

这里有一个模块划分时的关键设计原则：以员工信息为核心主数据，其余模块都围绕员工进行数据关联。考勤要放到某个员工名下，请假要和某个员工绑定，薪资更离不开员工信息和部门归属。把这条主线理清楚，后面设计数据库时就不会东一榔头西一棒槌。

部门管理看起来简单，但设计时要注意层级关系的表达。比如一个公司有研发部，研发部下又分后端组、前端组，这种父子关系在系统里需要通过部门表的父级字段来体现，界面上则用树形结构展示。同时，部门删除一定要做限制，如果部门下还有在职员工，应该拦截删除操作，否则员工档案就会变成无归属的“孤儿数据”，这在人事管理中是绝对要避免的。

1.3 角色权限的三层划分

权限设计是 HR 系统绕不开的环节，因为薪资、员工联系方式这类数据非常敏感，不可能让普通员工随意查看全部同事的信息。这套系统的权限模型采用了最常见的 RBAC 设计，也就是“用户-角色-权限”三层结构。比如创建三个角色：系统管理员、HR专员、普通员工。管理员能进系统管理模块，HR能操作员工和薪资数据，普通员工只能看到自己的档案、考勤和请假记录，以及提交申请。

在实际实现时，权限控制要拆分成两个层面：一是功能权限，也就是某个角色能访问哪些菜单和按钮，这是通过数据库权限表和后端拦截器共同实现的；二是数据权限，也就是同一个角色下不同的人能看到哪些数据范围，像部门HR只能看本部门的员工，这一层在毕设或中小型项目中往往做简化处理，主要是靠查询条件里拼上部门ID来完成。这个取舍是合理的，完整的数据权限体系实现成本很高，对于几百人规模的使用场景来说，功能权限加上部门过滤已经完全够用。

2. 技术架构：为什么偏偏是 Java + SpringBoot + SSM

2.1 SSM 三件套各自管哪一层

SSM 指的是 Spring、Spring MVC、MyBatis 这三个框架的组合，它们的分工可以类比成一个小型公司的三个部门：Spring 是总经理办公室，负责统筹管理所有对象的创建和依赖关系，也就是所谓的 IoC 容器和依赖注入；Spring MVC 是前台接待，所有请求都由它接收，然后根据 URL 分发给对应的业务部门处理；MyBatis 是档案室，专门负责和数据库打交道，把 SQL 写在 mapper 文件里，执行完再把结果映射成 Java 对象。

这三者配合起来的关系链是：前端页面发起HTTP请求，Spring MVC 的 Controller 接收请求，调用 Service 层的业务方法，Service 内部通过 MyBatis 的 Mapper 接口访问数据库，数据返回后再逐层回传，最终由 Spring MVC 渲染页面或返回 JSON 数据。整个过程清晰直接，特别适合中小型业务系统。这也是为什么这套系统没有引入更复杂的技术框架，因为在这个量级的业务逻辑下，SSM 的复杂度刚刚好，出问题也容易排查。

2.2 那 SpringBoot 又扮演了什么角色

用传统方式搭建 SSM 项目是件挺折磨人的事，要写一堆 XML 配置、配数据源、配事务管理器、配视图解析器，稍不留神版本就对不上。SpringBoot 的出现把这套繁琐的配置大幅简化了，它采用的是“约定优于配置”的思路，把常用的默认配置全部内置好，你只需要在 application.yml 里写上数据库连接信息、端口号、文件上传大小等少数字段就能启动项目。更关键的是，SpringBoot 内嵌了 Tomcat 容器，以前要单独安装 Tomcat 再把 war 包扔进去部署，现在一个命令 java -jar 就能直接跑起来，这对于开发调试和后期交付都方便太多。

这里有个容易让人产生误解的概念要讲清楚：SpringBoot 并没有替代 SSM 中的任何一个组件，它的底层依然使用 Spring 容器来管理 Bean，依然支持 Spring MVC 来处理请求，依然可以和 MyBatis 无缝整合。所以更准确的说法是，这个项目是用 SpringBoot 作为底座，把 SSM 整合得更加方便易用。

2.3 单体架构还是微服务，别陷入过度设计

我在指导别人做这类系统时，经常有人问“要不要做成微服务”。我的建议非常明确：不要。微服务是为了解决大规模团队的独立部署、独立扩缩容、多技术栈混合等复杂问题，而 HR 管理系统这类业务，即便是大型企业成熟产品，也完全可以用单体架构支撑，更不用说这套面向中小规模场景的系统了。做成单体架构，代码结构简单，调试方便，部署就是一个 jar 包，一台普通服务器就能跑得稳稳的，运维成本极低。答辩时如果被问到架构选型，这个理由是非常站得住的。

技术上选用单体架构还有一个好处，就是数据一致性更容易保证。比如薪资核算这个流程，涉及到员工基本工资、考勤扣款、请假天数等多个表的数据，在单体应用里可以直接用本地事务把整个操作包起来，任何一个环节出错都能整体回滚，不会出现跨服务分布式事务那种让人头疼的补偿问题。架构是为业务服务的，几万字代码的项目上微服务，属于给自己找麻烦。

2.4 权限方案与统一返回结构的设计取舍

在登录认证方面，常见的有两种方案：传统 Session 会话和 JWT 令牌。这套系统采用的是 Session 加拦截器的组合，登录成功后把用户 ID 和角色信息放入 Session，然后注册一个全局拦截器，拦截所有需要登录的请求，从 Session 里校验用户是否存在。这个方案实现简单、状态管理方便，服务端随时可以踢人下线，非常适合非前后端分离或者后端渲染为主的项目。如果你的版本是前后端完全分离，用 VUE 或 React 单独部署，那建议改用 JWT 方案，请求头里带 token，后端通过拦截器解析 token 并校验有效期。

不管哪种方案，响应给前端的数据格式一定要统一。我习惯在项目里定义一个 Result 类，包含 code、message、data 三个字段，所有接口都返回这个结构，成功时 code 为 200，失败时根据业务场景返回不同的错误码。同时再配一个全局异常处理器，用 @RestControllerAdvice 捕获项目中的运行时异常和业务异常，统一转成 Result 格式返回。这样一来，前端处理数据时完全不用关心各种异常情况，逻辑清爽不少，这也是区分一个项目是不是“野路子”的细节标准之一。

3. 数据库设计：九张表如何撑起整个系统

3.1 核心数据表的职责与关系

数据库设计是这类管理系统最重要的环节，表结构一旦定下来，后续所有代码都在为它服务。这套系统的数据库我梳理为九张核心表，每一张都有明确的职责边界：用户表存登录账号信息，角色表定义角色类型，菜单权限表维护系统功能点，部门表维护组织架构，员工表存员工基本信息，考勤表和请假表记录员工日常行为，薪资表按月存储发放记录，中间表 user_role 和 role_menu 分别建立用户与角色、角色与权限的多对多关系。

表之间的核心关系链是：用户表通过 user_role 关联角色，用户通过员工ID关联到员工表，员工表通过部门ID关联到部门表，考勤、请假、薪资三张表又分别通过员工ID关联回员工表。这是一张典型的以员工为核心主数据的星型模型，查询时从员工表出发可以很方便地关联到任意业务子表。设计时要把用户账号和员工档案分开，原因很简单：一个员工可能换账号，一个账号也可能在员工离职后需要停用，两者逻辑上独立才能分别管理。

3.2 关键建表细节与 SQL 实现选段

员工表可以说是整个系统信息量最大的表，字段设计直接决定了后续功能的复杂度。核心字段我给出这段建表 SQL 做个参考：

CREATE TABLE employee ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键ID', emp_no VARCHAR(20) NOT NULL UNIQUE COMMENT '员工编号', name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT DEFAULT 0 COMMENT '性别 0-未知 1-男 2-女', dept_id BIGINT NOT NULL COMMENT '所属部门ID', position VARCHAR(50) COMMENT '职位', phone VARCHAR(20) COMMENT '联系电话', email VARCHAR(100) COMMENT '邮箱', hire_date DATE COMMENT '入职日期', status TINYINT DEFAULT 1 COMMENT '状态 1-在职 0-离职', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_dept_id (dept_id), INDEX idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='员工表';

这里有几个设计上的小心思值得说明。员工编号 emp_no 设置唯一约束，它相当于员工在公司里的“身份证号”，在薪资、考勤等所有业务操作中都用它做逻辑关联，比用自增主键更稳定；dept_id 和 status 分别建立索引，因为这两个字段会频繁出现在查询条件里，加索引能明显提升分页查询效率；status 字段用的是 TINYINT 而不是直接删除记录，这属于软删除策略，员工离职后档案依然保留，只是状态变为离职，这对于后续追溯历史工资和考勤记录非常重要。

请假表的设计则要重点考虑流程状态字段。我一般用 status 表示审批状态，用数字 0、1、2 分别代表待审批、已批准、已驳回，再用 approver_id、approve_time、approve_comment 三个字段记录审批人和审批意见。这组字段是流程留痕的最低配置，没有它们，审批记录就只是几个数字，完全说不清楚“谁在什么时候批的”。工资表的表结构里除了基础工资 base_salary，还要留出 bonus 和 deduction 两个字段，用来表示绩效奖金和五险一金扣款等变动项，后端按月计算最终实发金额 amount，这样可以保证即便基础工资有调整，历史月份的工资记录也不受影响。

3.3 数据库设计的几个避坑清单

第一点，密码绝不能明文存储。很多学习项目为了图省事直接存明文密码，这在真实系统里是绝对不允许的。推荐的做法是用 BCrypt 加密算法，它每次生成的哈希串都带有随机盐值，就算两个用户设置了完全相同的密码，存储结果也不一样，攻击者无法通过彩虹表反推。代码实现时不需要引入整个 Spring Security 框架，单独引入 spring-security-crypto 依赖就足够。

第二点，不要过度迷信数据库物理外键。用 FOREIGN KEY 约束虽然能保证数据一致性，但在高并发插入操作下会影响性能，而且删除时容易报约束错误。这套系统采用的是逻辑外键，也就是只在业务层面保证关联关系，数据库层面通过索引来加速查询。这样做的好处是代码对数据的管理更灵活，例如员工离职时可以先改状态再异步清理数据，而不会被外键卡死。

第三点，日期时间字段处理要提前定好规范。MySQL 8.0 以上的时区问题很麻烦，连接参数里一定要加上 serverTimezone=Asia/Shanghai，否则会出现时间相差8小时的诡异问题。所有表统一使用 DATETIME 类型存具体时间，日期字段像入职日期、请假日期用 DATE 类型，避免把日期和时间混在一起增加查询难度。

4. 实战环节：从零搭一个 HR 系统的关键代码

4.1 环境准备与工程骨架搭建

开发这套系统我建议使用的环境组合是：JDK 1.8、Maven 3.6 以上、MySQL 5.7 或 8.0、IDEA 开发工具。SpringBoot 版本建议选择 2.5.x，这个版本和 JDK 8 的兼容性最好，而且大量第三方依赖的适配信息都比较完善。切记不要贸然使用 SpringBoot 3.x，因为 3.x 底层是 Spring Framework 6，要求 JDK 17 起步，如果你对版本迁移没有把握，直接用 2.5.x 是最稳妥的选择。

工程目录结构建议按下述分层来组织，这是 SSM 项目最经典的分层方式：

src/main/java/com/example/hrms ├── controller # 控制层，接收请求，返回结果 ├── service # 业务层，处理业务逻辑和事务 ├── mapper # 数据访问层，MyBatis的Mapper接口 ├── entity # 实体类，对应数据库表 ├── common # 公共模块，统一返回结果、异常处理、工具类 ├── config # 配置类，拦截器注册、文件上传等 └── HrmsApplication.java # SpringBoot启动类

分层最重要的意义在于让依赖关系单向流动：Controller 依赖 Service，Service 依赖 Mapper，不能反过来。有的初学者图省事，在 Controller 里直接调用 Mapper 的方法，虽然短时间内项目能跑通，但后期如果要改业务逻辑，会发现到处都在改，非常痛苦。坚持分层开发，职责边界清晰，也方便写单元测试。

4.2 登录认证与拦截器的实现

登录接口的逻辑不复杂，核心是两步：第一步用用户名查出用户记录，比对密码是否正确；第二步如果匹配成功，将用户ID、用户名、角色信息存入 Session。密码比对我使用的是 BCryptPasswordEncoder 的 matches 方法，因为数据库里存的是 BCrypt 加密后的密文，不能直接和明文等号比较。

拦截器是权限控制的执行者，我写了一个 LoginInterceptor 类，核心逻辑如下：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } // 从Session中获取用户信息，判断是否登录 Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.setContentType("application/json;charset=UTF-8"); response.getWriter().write(JSON.toJSONString(Result.error(401, "未登录或登录已过期"))); return false; } // 角色权限校验：通过handler方法上的注解判断 HandlerMethod handlerMethod = (HandlerMethod) handler; RequiresPermission requiresPermission = handlerMethod.getMethodAnnotation(RequiresPermission.class); if (requiresPermission != null) { String required = requiresPermission.value(); // 从Session中取出角色权限列表，判断是否包含required if (!hasPermission(request, required)) { response.getWriter().write(JSON.toJSONString(Result.error(403, "无权限访问"))); return false; } } return true; } }

这段代码里有两个值得学习的点。第一，通过自定义注解 RequiresPermission 标注在 Controller 方法上，拦截器在运行时读取这个注解并校验当前用户的权限信息，这种方式比每个方法里手动写权限判断要优雅得多；第二，返回结果统一使用 Result 对象转 JSON，哪怕是认证失败，前端拿到的数据结构也和正常响应完全一致，方便统一处理。

拦截器写完后，还要在 WebMvcConfigurer 配置类里注册它。注意注册时要用 addInterceptors 方法，并设置排除放行的路径，比如登录接口 /login、静态资源 /static/**、验证码接口等。这个步骤很容易被忽略，一旦忘记排除登录接口，就会形成死循环：登录接口也需要拦截器验证，但用户还没登录。

4.3 员工管理核心接口的实现细节

员工管理页面是系统里使用频率最高的功能，通常会做成分页列表，带多个筛选条件。查询条件一般包括姓名关键字、部门、入职日期区间、员工状态。这里使用 PageHelper 分页插件来简化分页逻辑，代码如下：

@Service public class EmployeeServiceImpl implements EmployeeService { @Override public PageResult<EmployeeVO> pageQuery(EmployeeQuery query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); List<EmployeeVO> list = employeeMapper.selectByCondition(query); PageInfo<EmployeeVO> pageInfo = new PageInfo<>(list); return PageResult.of(pageInfo.getTotal(), pageInfo.getList()); } }

PageHelper 的工作原理是拦截 MyBatis 执行的 SQL，自动拼接 LIMIT 语句，用起来非常方便。但有一个坑必须注意：PageHelper.startPage 之后紧跟的那一条查询语句才会被分页拦截，如果中间插了其他查询操作，分页就会错乱，所以 startPage 必须和下一条 Mapper 查询紧挨在一起写，中间不要插入任何代码。

新增员工接口需要注意的是编号唯一性校验。员工编号是业务主键，提交时先按 emp_no 查一次库，如果已存在就直接抛出业务异常。保存时还需要处理照片上传，我建议将上传的图片保存在服务器本地路径或对象存储中，数据库只存文件访问路径的字符串字段，不要用 BLOB 字段直接存二进制，否则数据库会变得异常臃肿，查询性能也会下降。

4.4 请假审批流程的状态流转实现

请假审批是这套系统里最接近“工作流”的功能，但完全没有必要引入 Activiti、Flowable 这类重量级工作流引擎。对于请假这种典型的单级或两级审批场景，用状态字段加权限控制就能完美实现，代码简洁且逻辑清楚。请假流程的状态流转用下面的代码段来表示：

public void approve(Long leaveId, Integer approveResult, String comment, Long approverId) { LeaveRequest leave = leaveMapper.selectById(leaveId); if (leave == null) { throw new BusinessException("请假记录不存在"); } // 校验当前状态必须是待审批 if (leave.getStatus() != 0) { throw new BusinessException("该申请已被处理，请勿重复操作"); } // 审批结果：1-通过 2-驳回 int newStatus = (approveResult == 1) ? 1 : 2; leave.setStatus(newStatus); leave.setApproverId(approverId); leave.setApproveTime(new Date()); leave.setApproveComment(comment); leaveMapper.updateById(leave); }

这段简单代码背后藏着一个很重要的设计思想：用状态机思维管理流程。状态只能按预定路径流转，比如从待审批到已批准或已驳回，不能从已批准再变回待审批。校验“当前状态必须是待审批”这一步，就是状态机的落地保护。如果申请被驳回后允许员工修改再重新提交，那过程就是把状态从已驳回重置为待审批，同时清空审批意见。这样虽然代码简单，但每一步都清晰可查。

薪资模块的权限控制要单独特别注意。工资数据的查看和导出接口，我建议在 Controller 方法上同时标注这个权限注解，并且限制只有 HR 角色或管理员角色才能访问。工资计算时，请假的已批准天数要从固定工资里按对应比例扣除，这个规则如果太复杂，不要全堆在 SQL 里写，而是由 Service 层从数据库取出基础数据后在内存里计算，更容易保证逻辑正确和单元测试覆盖。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

这部分我整理了开发调试这套系统过程中最常遇到的几个问题，按现象、原因和解决方案整理成表，方便你快速定位。

5.2 三个值得记住的排查故事

第一个故事发生在 MySQL 8.0 环境。项目在本地 5.7 跑得好好的，放到另一台装了 MySQL 8.0 的机器上就报连接超时，反复检查密码和端口都没问题。后来发现 8.0 版本对时区配置变得严格，JDBC 连接串必须显式指定 serverTimezone，否则驱动无法确定会话时区。当时加上 serverTimezone=Asia/Shanghai 后一切恢复正常。这个问题在 MySQL 5.7 上不会出现，因此容易忽略。

第二个故事更隐蔽，页面样式全部丢失，CSS 文件加载不出来。我第一反应是静态资源路径写错了，检查了半天发现都没问题，最后才意识到是拦截器把所有请求都拦住了，配置的时候图省事用了一个/**通配符，把/static/**路径也拦在了外面。从那以后我再写拦截器配置，都会在注册时仔细区分路径匹配规则，静态资源和登录接口必须加进排除列表。

第三个故事是典型的依赖版本冲突。项目里同时引了 Old JSON 库和 Jackson 库，Controller 返回对象序列化时，两种库的注解混用导致实体类中部分字段无法序列化，前端收到的 JSON 缺失字段。排查时用 postman 打接口直接看响应，发现正常接口数据完整，只有特定接口缺字段，逐步对比后才锁定是注解优先级冲突。解决办法是删除多余依赖，统一使用 SpringBoot 默认的 Jackson 作为 JSON 处理工具。这个经验告诉我，写依赖时一定要克制，能用 SpringBoot 原生能力解决的问题就不要额外引库。

5.3 调试文档的价值与写法和演示流程

调试文档在这个项目里扮演的角色，不是简单的“安装步骤”，而是一份可以从零到一复现系统的操作指南。我在整理这套项目的调试文档时，会严格按这个顺序写：环境版本确认清单、配置文件每项参数的说明、初始化数据库脚本执行方法、启动步骤及验证入口、核心功能测试用例。里面一定要包含每个接口的测试数据，例如登录用哪个账号密码、新增员工填什么参数、薪资计算的期望结果是多少，这些内容能极大降低使用者上手时摸不着头脑的概率。

讲解视频的录制也很有讲究，不能照着代码逐行念。我的建议是按照业务场景来演示：先演示管理员登录，创建部门和角色；再演示 HR 添加员工并导入考勤；然后切换到员工账号提交请假申请；最后回到管理员账号审批并计算工资。让观看者跟着一条完整的业务线走下来，比单纯罗列功能点要有效得多。

6. 文档组织与答辩追问准备

6.1 技术文档怎么组织才有价值

如果这套系统是用于毕设或者项目评审，技术文档的结构建议按章节推进，写的时候立足“从问题到方案”的思路。摘要部分要直接用两三句话点明系统解决的核心问题和采用的关键技术；需求分析章节按功能模块逐一说明业务流程；系统设计章节放架构图和模块划分；数据库设计章节先画 ER 图再用表格列出字段说明；实现与测试章节放关键代码片段和测试截图。写文档时不要复制粘贴大段代码，重点是解释“为什么这么实现”，评审老师更关心你的设计思路。

这个项目交付包里的 LW 部分（即说明文档）建议和调试文档分开。调试文档面向的是“如何跑起来”，语言要口语化、步骤要傻瓜化；正式说明文档面向的是“系统怎么做出来的”，语言要规范、推理要闭环。两种文档定位不同，混在一起会让两者都显得不够专业。

6.2 答辩评审现场的追问应对

答辩时，评委会集中提问技术选型和业务细节，这里挑几个高频问题分享一下应对思路。

为什么选 SSM 而不是 Spring Boot 全家桶？答案要点是：SSM 是经典组合，理解 Spring 核心原理和 MyBatis 运行机制更直接，很多老业务系统也是这个架构，掌握它有利于后续维护和迁移。而站在项目本身实际使用 SpringBoot 作为整合底座时，则强调它简化了配置和部署。

权限是怎么实现的？把 RBAC 的三层关系讲清楚，再结合拦截器代码说明认证和鉴权流程，基本就能稳住。

密码如何保证安全？mention BCrypt 加密和随机盐机制就够了，要是时间允许，可以再顺带讲一讲为什么不能使用 MD5 加盐这种容易被暴力破解的方案。

数据库为什么不用外键？回答思路是：逻辑外键更适合高并发和灵活的业务操作，通过应用层保证一致性，数据库索引提供查询性能。如果评审追问数据一致性怎么保证，就把 Service 层事务管理搬出来说。

如果被问到项目亮点，我不建议说“界面好看”或者“功能齐全”，最好说设计层面的亮点，比如统一返回结构加全局异常处理、状态机控制审批流程、软删除保证单据可追溯，这些细节会让人觉得你具备实际工程经验。

最后说点个人体会

接这类 HR 系统时最容易犯的错误是一开始就想着把功能做全，结果项目进入中后期后，核心流程反而没打磨好。我的经验是先把员工管理、部门管理、登录权限这三条最核心的链路跑通，形成能用的最小闭环，然后再逐步补考勤、请假、薪资这些外围模块。开发过程中配套保持调试文档的实时更新，哪怕只是记录一个环境安装踩坑的小细节，对后续交付也会有大帮助。系统做完之后可以想想还有哪些能自然扩展的地方，比如数据导出、日志审计、消息提醒，这些都是低成本高感知的加分项，但前提依然是先把基础模块做稳了再说。