我先整理一下思路。Spring Boot人力资源管理系统HRMS是Java后端开发中非常典型的实战项目每年都有大量毕业生选它做毕设也有很多在职开发者把它当入门第一个全栈项目。但你真动手去做的时候就会发现网上类似的代码一抓一大把能跑通的也不少可一旦你要加权限、算工资、做出勤统计就全乱套了。问题通常不是Spring Boot本身而是对业务模块边界、数据表关系、状态流转这三件事没有提前想清楚。这篇文章我会按真实项目的推进顺序来讲从功能边界划分到技术栈选型再到数据库设计、后端核心逻辑、权限模型最后聊聊前端集成和部署时最常见的几个坑。全程用我实际开发过的人力资源系统经验来写代码可以直接抄但更希望你能理解每个设计背后的理由。1. 项目动工前的功能边界划分人力资源系统不只是“员工增删改查”很多人在设计HRMS时第一反应就是“员工管理、部门管理、考勤管理”然后直接开写。这没错但你会发现写到一半工资核算怎么算考勤异常怎么处理审批流走完状态怎么变更全都没有提前设计导致Service层越写越臃肿一个方法塞了几百行业务逻辑。1.1 核心模块到底该拆多细我经过几轮实际迭代后最终把人力资源管理系统拆成了七个模块组织架构模块部门表、岗位表、部门负责人关系员工信息模块入转调离全生命周期包含员工基本信息、合同信息、学历信息、紧急联系人考勤管理模块排班、打卡记录、请假/出差/加班申请、月度考勤汇总薪资管理模块薪资项配置、月度薪资计算、薪资条查看、社保公积金计算招聘管理模块职位发布、简历投递、面试安排、录用审批培训管理模块培训计划、报名、培训记录系统管理模块用户管理、角色权限、操作日志、数据字典这七个模块不要一次性全做完。我建议第一版只做组织架构、员工信息、考勤、薪资、系统管理五个招聘和培训放到二期。原因很简单招聘模块涉及简历解析、面试流程培训模块涉及课程资源上传这两块的复杂度和核心人事流程不在一个量级。如果你是在做毕设五个模块已经能写出足够有说服力的论文如果是企业项目先跑通核心人事流程再迭代扩充是更务实的选择。1.2 状态流转是设计阶段最容易遗漏的隐含业务每个模块都有状态字段比如员工状态在职/试用/离职、请假状态待审批/已通过/已驳回、薪资状态未核算/已核算/已发放。状态一定要在数据库设计阶段就定好枚举值并且把状态流转图提前画出来。以请假为例我见过很多系统的请假流程是这样写的用户提交请假管理员看到后直接修改状态为“已批准”。表面看没问题但一旦加上“部门经理先审批HR复核”这种两层审批代码就乱套了。所以在前期设计时我会给每个审批类业务定义好统一的审批状态模型0草稿保存未提交1待审批提交后进入审批流2审批中部分审批节点已完成3已通过全部审批节点完成4已驳回任一节点驳回5已撤销提交人撤销这个状态机在后续所有的业务模块里统一复用界面上的按钮显隐、列表颜色、流程角色全部根据状态字段判断。核心原则是状态字段只存最终业务状态审批流转的中间过程不要用数据库字段去存而是记录在审批实例表中。1.3 用一张数据字典约束全局字段命名字段命名不统一是后期维护最头疼的事。比如“员工编号”有的人叫employeeId有的人叫empNo还有的叫staffCode数据库表名一会儿用employee一会儿用staff_info。我建议在项目启动时专门创建一个数据字典文档或者直接在系统里做一张数据字典表把每个字段的中文名、英文名、类型、长度、枚举值全部定义清楚。拿员工状态举例字段名类型长度说明枚举值employ_statusvarchar16员工在职状态TRIAL试用、REGULAR正式、PROBATION实习、TERMINATED离职employ_typevarchar16用工类型FULL_TIME全职、PART_TIME兼职、OUTSOURCING外包contract_typevarchar16合同类型FIXED固定期限、NON_FIXED无固定期限、LABOR劳务派遣这张表要在开发前定稿审评代码时拿着它逐字段核对。我踩过的教训是项目开发到一半因为新增一个“员工来源渠道”字段导致前后端三处联调、数据库迁移、历史数据清洗全部重做非常消耗时间。2. 技术选型为什么是Spring Boot版本到底怎么定人力资源管理系统是典型的CRUD密集型业务系统选型逻辑并不复杂稳定大于新潮生态成熟度优先。Spring Boot在这个领域是最合适的选择这一点没什么争议。真正需要花时间想清楚的是几个细节选型。2.1 Spring Boot版本选择的实际体验我通常建议新项目直接用Spring Boot 3.x系列的最新稳定版比如3.2.x或3.3.x。Java基础用17或21不要再回头看Java 8。这里有个关键点需要注意Spring Boot 3.x是基于Jakarta EE的原来的javax.servlet全换成了jakarta.servlet。网上大量旧教程里的代码是javax包的你直接用会报“ClassNotFoundException”。比如引入Spring Security或Servlet相关依赖时导入的包名一定要写成jakarta.servlet.http.HttpServletRequest而不是javax.servlet.http.HttpServletRequest。还有一个小细节是Spring Boot 3.x里很多自动化配置的行为变了。比如spring.factories机制换成了AutoConfiguration.imports自定义Starter的老套路失效。你如果要集成第三方组件得去META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports这个文件里配置自动装配类。我在一次集成金仓数据库驱动时在这里卡了很久后来才反应过来是AutoConfiguration机制变了。2.2 持久层框架MyBatis与MyBatis-Plus的取舍HRMS系统里大多数是单表查询和简单的多表关联查询直接用MyBatis手写SQL会非常零碎。我推荐使用MyBatis-Plus因为它在MyBatis基础上提供了通用Mapper和LambdaQueryWrapper能省掉大约60%的重复SQL。但这里我有个原则查询还是要自己写SQL。MyBatis-Plus的Wrapper适合做简单的等值查询、分页查询但一旦涉及多表Join、复杂统计比如计算月度出勤天数、加班时长汇总Wrapper就变得无比难读性能也不好控制。我的做法是所有主表CRUD用MyBatis-Plus所有统计查询、报表类查询一律写在XML里用自定义SQL实现。具体配置我一般写成这样mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0注意那个logic-delete-field如果你用了逻辑删除所有实体类都要加上deleted字段并且查询时MyBatis-Plus会自动帮你拼接deleted0条件。但自定义SQL里不会自动加你必须自己在XML里写where deleted 0这个很容易漏掉漏掉后查出来一堆已删除数据非常尴尬。2.3 Maven多模块结构还是单模块人力资源系统这种规模的项目我建议直接用Maven多模块但也不要过度设计。我常用的模块划分如下hrms-parent父POM ├── hrms-common通用工具、异常、常量、枚举 ├── hrms-framework框架配置、安全认证、日志、MyBatis配置 ├── hrms-system系统管理模块用户、角色、菜单、字典 ├── hrms-hr人事模块组织、员工、考勤、薪资 └── hrms-admin启动模块Application类、application.yml这样做的好处是你在hrms-hr里写考勤业务不会因为误操作改到系统管理的代码而且后续你要单独给薪资模块出一个微服务直接把hrms-hr拆出去就行。如果你觉得多模块复杂单模块也完全可以前提是包结构要严格分层。我见过太多单模块项目最后搞成包名混乱、Service互相乱注入的烂摊子。多模块从一开始就为你划好了物理边界。3. 数据库设计表结构定生死三张核心表如何建模数据库设计直接决定了后面写代码的难度。HRMS系统的数据库设计核心是员工表、考勤表、薪资表以及它们之间的关系。我在这里给出最实用的一套设计而不是教科书式的范式设计。3.1 员工表别把扩展字段一股脑塞进主表员工主表建议叫employee核心字段如下CREATE TABLE employee ( 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 COMMENT 性别 1男 2女 3保密, birthday DATE COMMENT 出生日期, id_card VARCHAR(18) COMMENT 身份证号, phone VARCHAR(20) COMMENT 手机号, email VARCHAR(100) COMMENT 邮箱, avatar_url VARCHAR(255) COMMENT 头像地址, department_id BIGINT COMMENT 部门ID, position_id BIGINT COMMENT 岗位ID, employ_status VARCHAR(16) COMMENT 在职状态, employ_type VARCHAR(16) COMMENT 用工类型, hire_date DATE COMMENT 入职日期, regular_date DATE COMMENT 转正日期, resign_date DATE COMMENT 离职日期, contract_deadline DATE COMMENT 合同截止日期, deleted TINYINT DEFAULT 0 COMMENT 逻辑删除, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT员工表;这个设计里有两个容易被忽视的点第一身份证号字段我用VARCHAR(18)而不是CHAR(18)因为有些数据可能带字母X而且未来可能会存香港身份证、护照号。CHAR(18)虽然长度够但存储时尾部空格处理会有隐形成本。第二我把员工的工作经历、学历、家庭成员、紧急联系人这些信息拆成了单独的表比如employee_education、employee_family用employee_id关联。这是经典的比冗余带来的后期收益大很多的设计——学历信息可能是多条记录本科、硕士塞在主表里就只能存一个最高学历反而丢了数据。3.2 考勤表记录与汇总分离考勤模块最容易犯的错误是为了页面展示方便直接设计一张“考勤记录表”每个员工每天的上下班打卡时间各一列再附加加班时长、迟到早退标志。结果月底做统计报表时SQL写得无比痛苦。我推荐的设计是“记录表汇总表”两张表CREATE TABLE attendance_record ( record_id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT NOT NULL, work_date DATE NOT NULL, check_in_time DATETIME, check_out_time DATETIME, status VARCHAR(20) COMMENT NORMAL正常 LATE迟到 EARLY_LEAVE早退 ABSENT缺勤, source VARCHAR(20) COMMENT 打卡来源FACE设备/APP/MANUAL ); CREATE TABLE attendance_summary ( summary_id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT NOT NULL, month VARCHAR(7) NOT NULL COMMENT 月份格式2025-06, should_days INT COMMENT 应出勤天数, actual_days INT COMMENT 实际出勤天数, late_count INT COMMENT 迟到次数, early_leave_count INT, absent_days INT, leave_days INT, overtime_hours DECIMAL(5,2), status VARCHAR(20) COMMENT DRAFT已生成 CONFIRMED已确认 LOCKED已锁存 );记录表存流水汇总表存统计结果。月底核算时定时任务读取记录表按employee_id和month聚合并写入汇总表。这样做有三大好处列表页查询汇总表数据量小速度快工资计算直接读取汇总字段无需现场计算记录表可以全量保存半年以上随时支持异常追溯。最后再加一个UNIQUE KEY(employee_id, month)防止重复汇总。3.3 薪资表薪资项不要写死薪资核算最大的坑是薪资结构不固定。有的员工有全勤奖有的员工有交通补贴有的员工有提成如果每加一个薪资项就去改表运维成本极高。正确做法是把薪资拆成“薪资项配置表员工薪资明细表月薪资结算表”。CREATE TABLE salary_item ( item_id BIGINT PRIMARY KEY AUTO_INCREMENT, item_code VARCHAR(30) COMMENT 薪资项编码BASE_SALARY, FULL_ATTENDANCE_BONUS..., item_name VARCHAR(100), item_type VARCHAR(10) COMMENT INCOME收入 DEDUCTION扣除, formula VARCHAR(255) COMMENT 计算公式占位 ); CREATE TABLE employee_salary_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT, item_id BIGINT, amount DECIMAL(12,2), effective_date DATE, expire_date DATE ); CREATE TABLE monthly_salary ( salary_id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT, month VARCHAR(7), total_income DECIMAL(12,2), total_deduction DECIMAL(12,2), net_salary DECIMAL(12,2), status VARCHAR(20) COMMENT DRAFT/CONFIRMED/PAID );这样每个员工的薪资构成是一组配置记录月底计算时遍历配置项算出总额再减去社保公积金、个税得到实发工资。用公式字段做弹性扩展比如“绩效工资基础工资*绩效系数”可以在公式里存一个模板字符串后台解析计算。对小规模项目来说这个设计的灵活度已经足够。4. 核心模块实现考勤核算、请假审批、工资生成的业务闭环数据库设计完之后接下来是最核心的部分业务逻辑怎么组织。我挑三个常见又容易出问题的业务来详细展开考勤判定的实现、审批流程的状态流转、工资自动核算。4.1 考勤异常判定迟到、早退、缺勤的算法考勤判定不能靠比较“打卡时间是否晚于上班时间”这么简单。原因是很多企业有弹性上班时间比如九点上班但迟到宽限10分钟还有夜间加班人员第二天可能十一点才上班。所以我设计的考勤规则是一个独立的配置表CREATE TABLE attendance_rule ( rule_id BIGINT PRIMARY KEY AUTO_INCREMENT, department_id BIGINT, work_start_time TIME NOT NULL DEFAULT 09:00:00, work_end_time TIME NOT NULL DEFAULT 18:00:00, late_grace_minutes INT DEFAULT 10, early_leave_grace_minutes INT DEFAULT 5, workday_type VARCHAR(10) DEFAULT MONDAY_TO_FRIDAY );然后是判定算法。对每条打卡记录先通过员工部门拿到规则再判断public AttendanceStatus evaluateStatus(AttendanceRecord record, AttendanceRule rule) { LocalTime checkIn record.getCheckInTime().toLocalTime(); LocalTime checkOut record.getCheckOutTime().toLocalTime(); LocalTime start rule.getWorkStartTime(); LocalTime end rule.getWorkEndTime(); if (checkIn.isAfter(start.plusMinutes(rule.getLateGraceMinutes()))) { return AttendanceStatus.LATE; } if (checkOut.isBefore(end.minusMinutes(rule.getEarlyLeaveGraceMinutes()))) { return AttendanceStatus.EARLY_LEAVE; } if (checkIn null || checkOut null) { return AttendanceStatus.ABSENT; } return AttendanceStatus.NORMAL; }这里要注意一定不能程序里硬编码上班时间因为不同部门用不同班次。另外考勤记录要从打卡设备或钉钉、企业微信接口同步过来同步的时候要按employee_idwork_date做去重同一个员工同一天有多条打卡记录的话取第一次和最后一次分别作为上下班时间。如果员工当天打了四次卡中午外出吃饭中间的记录要忽略。这个逻辑我在开发时忽略了导致有员工中午刷卡外出被算成早退后来加了一个“取最早和最晚”的逻辑才解决。4.2 审批流的设计不用工作流引擎用状态机就够很多人在人力资源系统里引入Activiti、Flowable完成审批流这在我个人看来属于严重过度设计。HRMS的审批流本质上就是请假、加班、出差、离职这几种每个流程的节点数量有限且固定比如请假发起-部门经理-HR没有必要为了追求通用性而引入一个重型工作流引擎额外部署表结构写流程定义XML后续调试还麻烦。我采用的方案是建一张审批实例表和一张审批记录表CREATE TABLE approval_instance ( approval_id BIGINT PRIMARY KEY AUTO_INCREMENT, business_type VARCHAR(30) COMMENT LEAVE/OVERTIME/BUSINESS_TRIP/RESIGN, business_id BIGINT COMMENT 业务单ID, current_node INT, max_node INT, status VARCHAR(10) COMMENT PENDING/APPROVING/APPROVED/REJECTED/CANCELED, submitter_id BIGINT, submit_time DATETIME ); CREATE TABLE approval_record ( record_id BIGINT PRIMARY KEY AUTO_INCREMENT, approval_id BIGINT, node_order INT, approver_id BIGINT, action VARCHAR(10) COMMENT APPROVE/REJECT, comment VARCHAR(500), operate_time DATETIME );请假表只要保留一个status字段与审批实例对应即可。审批人提交请假单后系统创建审批实例current_node1状态PENDING。部门经理登录后看到待办列表点击通过时程序判断current_node是否等于max_node等于则整个流程置为APPROVED业务表状态同步更新不等于则current_node加1状态变为APPROVING并生成下一条待办记录。这个方案的好处是代码量极少所有审批业务复用同一套逻辑。而且查询某个员工的待办事项只要查approval_record表里approver_id等于当前登录用户的记录即可性能很好。4.3 工资核算定时任务公式模板工资核算我采用定时任务触发。每月1号凌晨跑一次流程如下找出上个月所有在职员工入职日期上月最后一天且离职日期为空或上月最后一天对每个员工读取员工工资配置employee_salary_item计算基本工资、补贴、扣除项读上月考勤汇总attendance_summary按规则计算扣款/全勤奖汇总总收入、总扣除、实发工资生成monthly_salary记录工资状态置为DRAFT等待HR确认用Spring自带调度或者XXL-Job都可以。对单体应用Scheduled就够了但要注意你如果用集群部署了多个实例定时任务会重复执行。解决办法是使用分布式锁如Redis SETNX或者配置ShedLock。我早年做项目没注意这个集群两台服务器工资算了两遍闹出过发放金额翻倍的事故。现在无论项目多小凡是有定时任务我都会加一个简单的Redis锁Component public class SalaryGenerateTask { Scheduled(cron 0 0 2 1 * ?) public void generateMonthlySalary() { String lockKey hrms:salary:lock: LocalDate.now(); Boolean locked stringRedisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofMinutes(30)); if (Boolean.TRUE.equals(locked)) { try { salaryService.generateSalaryForLastMonth(); } finally { stringRedisTemplate.delete(lockKey); } } } }总之业务代码的灵魂是状态明确、规则配置化、重复执行安全。5. 权限模型与安全设计由角色权限到越权防护人力资源系统里除了员工表、考勤表还有大量个人隐私数据身份证号、薪资、家庭成员信息权限控制是重中之重。我采用的是经典RBAC模型配合Spring Security JWT实现无状态认证。5.1 表结构用户—角色—菜单—权限数据库层就四张表CREATE TABLE sys_user ( user_id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT COMMENT 关联员工表, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, status TINYINT DEFAULT 1, deleted TINYINT DEFAULT 0 ); CREATE TABLE sys_role ( role_id BIGINT PRIMARY KEY AUTO_INCREMENT, role_code VARCHAR(50) UNIQUE, role_name VARCHAR(50) ); CREATE TABLE sys_user_role ( user_id BIGINT, role_id BIGINT ); CREATE TABLE sys_role_menu ( role_id BIGINT, menu_id BIGINT );菜单表管理页面按钮和API权限前端通过路由控制页面显隐后端通过注解或拦截器控制接口权限。这里要注意的是后端权限一定不能省略。很多系统只做了前端按钮隐藏后端接口裸奔别人直接调接口就能批量拉取员工数据。我的习惯是Controller上统一加PreAuthorize或自定义权限注解按接口维度校验。5.2 Spring Security与JWT整合的细节Spring Boot 3.x中整合Spring Security的做法和2.x不太一样。核心配置如下Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf(AbstractHttpConfigurer::disable) .sessionManagement(session - session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth - auth .requestMatchers(/api/auth/login, /api/auth/captcha).permitAll() .requestMatchers(/api/admin/**).hasRole(ADMIN) .requestMatchers(/api/hr/**).hasAnyRole(ADMIN, HR) .anyRequest().authenticated() ) .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); return http.build(); } }JWT过滤器里主要做三件事从请求头取出Token解析Token拿到用户ID和角色把用户信息封装成Authentication塞入SecurityContext。代码结构大致如下Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token resolveToken(request); if (token ! null jwtUtil.validateToken(token)) { Integer userId jwtUtil.getUserId(token); ListString roles jwtUtil.getRoles(token); UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken(userId, null, roles.stream().map(SimpleGrantedAuthority::new).toList()); SecurityContextHolder.getContext().setAuthentication(authentication); } chain.doFilter(request, response); } }一个常见的坑JWT Token是无状态的但你需要在用户修改密码、被禁用时让老Token失效。解决方案是引入一个token版本号或redis黑名单。我的做法是在sys_user表加一个token_version字段每次改密码或禁用用户时自增版本号JWT里存tokenVersion校验时比对当前版本不一致直接拒绝。5.3 数据权限HR只能看自己部门的员工按钮权限解决的是“能不能访问”数据权限解决的是“能看到哪些数据”。人力资源系统里部门经理通常只能看本部门员工HR专员能看全公司但对薪资只有查看权无修改权这是更细一层的问题。简单项目里我直接用SQL拼接组织过滤条件查询员工列表时如果当前用户角色是DEPT_MANAGER自动添加WHERE department_id IN (子部门集合)的条件。更通用的做法是使用MyBatis拦截器自动注入数据权限SQL但复杂度较高小项目不推荐。我在项目里采用的方式是自定义一个数据权限注解配合AOP动态拼接查询条件同时在Service层显式传入查询条件避免不小心越权。虽然多写了几行代码但安全性显著提升。6. 前端Vue集成与生产环境部署那些文档里不写的事现在很多项目都是前后端分离Vue作为前端框架几乎成了标配。网上有热搜词vue打包放进springboot中说明很多人想直接把前端文件塞进Spring Boot的静态资源目录里这个方案可行但有一些细节必须处理对否则要么历史路由刷新404要么项目分开部署时接口跨域出问题。6.1 Vue项目与Spring Boot整合的两种方式第一种是彻底前后端分离前端Vue工程独立部署到Nginx后端Spring Boot独立部署通过Nginx反向代理转发/api请求。这是生产环境最推荐的方案但是需要两台服务器或一套服务器上两个进程对于毕设或个人项目来说增加了部署成本。第二种是把构建后的Vue静态资源放到Spring Boot的src/main/resources/static目录下然后打成一个jar包。这个方式适合演示、交付、毕设答辩非常方便。需要注意的点是Vue路由使用history模式时刷新非首页会出现404。解决办法是在Spring Boot里加一个控制器将非api和静态资源的请求转发到index.htmlController public class ForwardController { RequestMapping(value {/, /login, /dashboard, /employee/**, /attendance/**, /salary/**}) public String forward() { return forward:/index.html; } }更通用的写法是不列举每个路由而是定义所有非静态资源、非api的路径都转发到index.html。由于Spring Boot的静态资源处理和Spring MVC的路由匹配存在优先级问题推荐用一个较简单的PathPattern判断。Vite的base路径要配置成相对路径或根路径。如果jar包直接部署在域名根路径base设为/即可。如果部署在子路径下比如公司内网服务器上还有别的系统那base必须配置成子路径同时前端里所有静态资源引用、路由都要注意拼接这个非常容易漏。我在vite.config.ts里一般这样配置export default defineConfig({ base: process.env.NODE_ENV production ? / : ./, plugins: [vue()], build: { outDir: ../src/main/resources/static, emptyOutDir: true } })直接把构建输出目录指向Spring Boot的static目录省去手动复制。注意outDir路径要写对这里../是从前端工程目录往上一层再进入后端工程的resources目录。6.2 接口请求的跨域与上下文路径如果前后端分离部署跨域是绕不开的。解决办法有两种一种是后端配置CorsFilter一种是Nginx配置反向代理。我在开发环境用后端CorsFilter生产环境用Nginx代理这样前后端代码里写的API路径保持一致部署时只需要在Nginx加一条location规则。生产环境还有一个容易踩的坑Spring Boot的context-path。如果你设置了server.servlet.context-path/hrms那前端请求的baseURL就必须带上/hrms。但如果你把Vue静态资源放在static目录下首页请求的静态资源默认是不经过context-path的这里会出现资源加载路径和API路径不一致的情况。最简单的处理方式就是统一要么不用context-path整个系统部署在根路径下要么前后端所有请求都带context-path。6.3 在一些特殊组件上的选型教训前端组件库建议直接用Element Plus几乎HRMS需要的表格、表单、弹窗、树形控件、上传组件它都有封装。后端管理类系统自己手写组件既浪费时间又不容易做好看。有一个经验想分享上传头像/证件照时如果是毕设级别的项目尽量不要引入OSS对象存储本地服务器存储就够了。我在项目里写了一个FileController接收MultipartFile后保存到本地上传目录然后把访问路径返给前端。路径要配置成绝对路径加相对URL映射Configuration public class WebConfig implements WebMvcConfigurer { Value(${file.upload-dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadDir /); } }注意这里Linux和Windows路径写法有差别Windows下要写file:D:/hrms/upload/Linux写file:/opt/hrms/upload/。配置文件中不要写死用Profile区分。我见过很多人在Windows上开发正常部署到Linux后图片全部404就是因为路径没处理对。7. 联动调试时的排错经验从“能编译”到“能稳定跑”代码写完了功能也通了不代表项目结束了。真正花时间的地方在联动调试和生产环境稳定运行上。这一节我分享三个高频率出现的问题。7.1 MyBatis映射文件的自动驼峰转换很多人用MyBatis-Plus自带的BaseMapper查询时一切正常一到自定义SQL就发现映射出来的实体字段全部为null。绝大多数原因是配置里没开启map-underscore-to-camel-case。虽然MyBatis-Plus默认是开启的但如果你自定义的XML里用了resultType而不是resultMap数据库字段下划线到实体驼峰的转换依赖这把全局开关。我一般会在yaml里明确写上避免团队里有人覆盖配置后引发问题。还有就是多表查询时两个表都有同一字段名比如都有create_timeresultType自动映射会不知道把值赋给哪个属性。这种情况必须写完整的resultMap手动指定每个字段的column和property。不要偷懒否则查出来的结果是错的你还浑然不觉。7.2 JPA与MyBatis并存时的数据源冲突有些项目因为历史原因同时引入了Spring Data JPA和MyBatis这会引入非常复杂的事务管理顺序问题。我的建议是二选一不要共存。人力资源系统用MyBatis-Plus更直观用JPA虽然开发快但复杂统计查询很难受。如果非要并存要在多个Configuration里指定不同的SqlSessionFactory和TransactionManager并且注意Transactional默认事务管理器只能有一个另一个必须通过Transactional(transactionManager xxxTransactionManager)显式指认。7.3 定时任务与事务失效的排查思路工资核算、考勤汇总这类定时任务方法里如果使用Transactional却失效常见原因有两个一个是同一个类内部方法自调用比如SalaryService的generateSalary方法调用同类里的另一个Transactional方法事务拦截器不会生效另一个是异步方法Async和Transactional一起用时异步线程里的事务管理器与调用线程不是同一个事务默认无法传播。我的处理习惯是凡是涉及定时任务和异步的逻辑我都不会只依赖Transactional而是在方法内部手动控制事务边界或者把事务划分到最小方法上绝对不写一个大方法包Agent所有数据库操作。这样能避免你调试半天找不到事务为什么没回滚。提示排查事务失效问题时第一步先确认EnableTransactionManagement是否开启第二步确认事务方法的调用链是否有自调用第三步再怀疑数据库表引擎是否是InnoDB。MyISAM不支持事务这个基础问题偶尔还是会有人踩。8. 从开发到交付项目落地后的几处收尾优化功能都跑通后我还会花一到两天做几件收尾的事这些事直接决定了别人拿到这个项目后能不能顺利启动、答辩或评审时有没有好感。8.1 数据库初始化脚本与自动建表项目交付或开源时数据库脚本要放在src/main/resources/db/下并且用Flyway或Liquibase管理版本。Flyway配置非常简单spring: flyway: enabled: true baseline-on-migrate: true locations: classpath:db/migration在db/migration目录下放V1__init.sql、V2__add_xxx.sql这样带版本号的脚本新环境启动时自动执行建表和数据初始化。我见过太多项目把SQL脚本随便扔在与代码无关的doc目录里收到项目的人第一件事就是手动建库常有遗漏然后各种连接报错。用Flyway管脚本既省心又专业。8.2 日志规范与操作审计HRMS是敏感数据系统操作审计必须做。最简单的方式是AOP记录每一次Controller请求请求人、请求路径、请求参数脱敏、响应时间、操作结果。我在项目里封装了一个Log注解打在需要审计的Controller方法上AOP切面负责记录日志到sys_operation_log表。脱敏这部分要特别留意。身份证号、手机号、银行卡信息写日志时有泄露风险所以日志输出前必须做脱敏处理只保留前后各两位中间用星号代替。类似的还有对薪资查询接口即使数据库有权限也建议做字段级脱敏返回防止前端误用导致隐私泄露。8.3 性能基本体检分页、索引、大数据量模拟上线前我用Jmeter或Python脚本模拟了一批数据500个员工、每天2000条打卡记录、累计一个季度考勤发现列表页最开始响应要两秒多。定位后发现两个问题一个是员工列表查询没有分页一次性查询全部另一个是attendance_record表的work_date字段没有建索引月度汇总全表扫描。这两个问题解决后响应时间降到一百毫秒左右。所以我的建议是员工列表、考勤列表等所有列表查询默认开启分页不论数据量有多少表里凡是参与where条件或join的字段全部建上联合索引。以下这段索引设计几乎适用于所有HRMSALTER TABLE attendance_record ADD INDEX idx_emp_date (employee_id, work_date); ALTER TABLE attendance_summary ADD INDEX idx_emp_month (employee_id, month); ALTER TABLE monthly_salary ADD INDEX idx_emp_month (employee_id, month); ALTER TABLE sys_operation_log ADD INDEX idx_user_time (user_id, create_time);把性能问题扼杀在开发阶段比上线后被用户骂要好得多。9. 我踩过的一些“常规操作”意外给你做个参考最后聊几个不常被写成博客但实际项目里高概率会遇到的真实翻车现场。我不敢说一定发生在你身上但如果遇到了可以少走很多弯路。9.1 日期参数接收报错前端传“2025-06-01”这样的字符串给后端LocalDate类型参数Spring Boot默认支持。但如果传的是“2025-06-01 10:00:00”给LocalDateTime或者用了JSON传参且格式带T就会出现DateTimeParseException。解决办法是统一约定时间格式。我在项目中配置了一个Jackson全局限定spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时所有实体的时间字段都用java.time的LocalDateTime并在接收前端提交时用JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解统一格式。全局配置注解双保险基本能避免绝大多数前端后端格式不一致的问题。9.2 逻辑删除和唯一索引的冲突我在employee表里对empNo建了唯一索引配合逻辑删除字段使用。当员工A离职逻辑删除后HR入职一个员工B工号恰好想复用A的工号此时插入会违反唯一索引。这个问题是因为逻辑删除的数据还占用着唯一索引。生产环境遇到过两次很麻烦。解决办法有几个我采用的是“唯一索引改为联合唯一索引emp_no, deleted”因为逻辑删除deleted默认是0删除后deleted变成1联合唯一索引就能区分同一个工号又可以存在两条记录。但这里有个后续问题如果同一个工号被多次复用那需要将deleted的值带上时间戳比如删除时deleted字段直接存主键ID或当前毫秒数确保每次删除都产生不同的值。这点细节我强烈建议在设计表时就想好。9.3 Maven多模块测不出问题的坑多模块开发时hrms-common模块改动后其他模块经常看不到最新代码。原因是Maven内部模块依赖更新机制在某些IDE环境下不会自动reimport。我第一次遇到时还以为是代码没保存反复clean没用。解决办法是自定义一个父POM里禁用Maven的增量编译或者在模块依赖上不使用SNAPSHOT版本范围。最省心的方法就是开发时用mvn install把公共模块装到本地仓库再让其他模块引用。提示如果你用的是IDEA修改hrms-common后先执行Maven面板里对应模块的install再运行主启动类90%的“新代码不生效”问题都能解决。10. 这个项目后续还能怎么扩展人力资源系统做完第一版后扩展方向非常明确如果你的目的是学习或毕业设计可以有选择地往下面这几个方向延伸。10.1 升级为微服务架构把组织人事服务、考勤服务、薪资服务拆成独立模块用Nacos做注册中心用OpenFeign做服务间调用用Gateway做统一入口。这个扩展的难度不大因为前期已经用Maven多模块隔离了业务边界拆起来相对顺手。但你要清楚对于人力资源系统这种体量微服务带来的依赖治理成本可能超过收益除非有明确的性能或团队分工需求否则不要强行上。10.2 集成工作流引擎处理复杂审批如果业务方反复加审批节点、分支条件比如“请假三天以内部门经理审批三天以上HR和总经理都要审批”状态机就会变复杂。这个时候可以引入Flowable或Camunda把审批流程做成可拖拽配置的。接入过程不会特别复杂核心是把业务流程引擎与业务表解耦通过businessType和businessId在流程实例与业务数据之间建立映射。10.3 引入消息队列做异步通知员工自助申请、审批通过后想要短信/邮件通知可以引入RabbitMQ或Spring事件机制。如果在Spring Boot单体应用里很多通知场景可以用Spring的ApplicationEventPublisher完成不必上消息队列写起来极其清爽。只有将来要对接钉钉机器人、企业微信、多个外部系统时再上MQ做异步削峰和重试。10.4 前后端分离后进一步做数据可视化人力资源报表通常包括部门人员结构、学历分布、年龄分布、离职率曲线、薪资成本趋势。用Vue ECharts做一个独立的报表模块数据接口还是从Spring Boot的统计查询里出这会让项目的完成度和可视化展示效果提升一个档次。我个人在实际项目里的体会是Spring Boot人力资源管理系统最大的价值不在于技术有多深而在于通过这个业务场景把CRUD、权限、审批、定时任务、数据统计这些后端开发者的日常技能完整串联了一遍。你坚持把它从零做到能稳定运行、能给别人演示收获的绝不仅仅是一套代码而是一整套“面对模糊业务需求时如何拆解并落地的思路”。最后再分享一个小技巧设计任何一个“系统类”项目前先去下载两个真实的开源项目不管是什么语言的HRMS或ERP把他们的数据库表结构从头到尾看一遍再回过头设计自己的表。大多数你以为自己想出来的优秀设计前人早就踩过坑并且给出更好的答案了。这份习惯会让你少走很多弯路。
