简介面向企业内部人力资源管理场景的Java Web项目源码包以SpringMVC、Hibernate搭建后端业务引入百度ECharts完成数据可视化并支持Excel批量导入导出适合Java Web学习者、初级开发人员以及需要快速搭建人员管理模块的团队参考。整个压缩包共90个文件以Java与JSP源码为主辅以XML配置、CSS与JS样式脚本、properties资源文件以及少量图标字体基本覆盖Maven工程从编码到部署所需的常见文件类型包体约784KB目录划分清晰从包内文件分布可识别出控制器、业务逻辑、数据库映射及前端展示等多个层面适合整体研读。已有362人学习通过阅读源码可深入理解SpringMVC的请求分发、Hibernate的对象关系映射、ECharts图表构建、Excel导入导出等核心技术思路。项目还包含完整的Eclipse与Maven工程配置以及前端页面素材方便直接导入开发环境运行调试也可作为课程设计或毕业设计的参考模板对于需要实现人员信息增删改查、部门统计、报表展示等功能的场景也可以从中获得直观的落地参考。1. 从Excel台账到系统管理这个项目是怎么被逼出来的你能想象一家三百多人的公司最核心的人员管理系统居然靠三张Excel表撑了整整三年吗我接手这件事的时候人事部的花名册已经增长到320行月底考勤统计要花上一整天部门调整之后历史数据根本没处查。最后逼着我从头写了一套系统。这可能是最适合大多数中小企业的做法不买昂贵的人力资源套件不请外包自己搭一个够用、能改、能维护的人员管理系统。下面这些内容就是这套系统从需求分析到数据库设计、再到数据迁移和上线复盘的全过程适合正在做内部管理系统的开发、运维同学参考。1.1 三张Excel表撑起的人事部问题出在哪当时人事部手头就是三张表员工花名册、考勤汇总表、入离职台账。听起来挺简单实际跑起来全是坑。先说花名册。320行数据里有两个“王磊”一个在技术部一个在销售部手机号有的是“138-1234-5678”有的是“13812345678”还有用括号括起来区号的部门一列写的是“市场部”但有人填的是“市场营销部”口径全凭当时打字的心情。到了月底统计人头数光是人工核对这些不一致就得耗掉半天。再说考勤汇总。考勤机导出的原始打卡记录是文本格式HR把记录粘贴进Excel再用VLOOKUP和员工信息匹配。日期格式稍微不一样函数就返回#N/A。最离谱的是有个月一个人离职了但考勤记录没删月底给人家算了满勤还是员工自己发现工资多了才查出来。入离职台账相对好一点但完全是手工登记。老板问“这个季度市场部离职率是多少”HR只能翻开台账一条条数数完还得手动去花名册里核对谁在职谁不在统计结果出来已经是第二天了。这些问题的本质不是Excel不好用而是人员数据天然带有“状态变化”和“组织归属变化”纯表格根本无法表达这种动态关系。数据库能做的是把这些变化变成一条条可以查询、可以追溯的记录。1.2 需求边界第一版什么必须做什么砍掉本来我以为这个系统要覆盖人事全流程需求访谈做完才发现真正高频、易错、老板看得见的需求就那么几个员工档案、组织架构、入转调离、考勤假勤、权限控制、花名册导出。这六项是第一版必须做的。薪资算法各家不同而且严重敏感第一版直接砍掉。绩效规则复杂而且部门之间标准不一样也砍掉。培训、招聘、合同到期提醒这类低频功能先不做后续用列表查询替代。砍需求这件事比加需求更需要克制。自研系统的核心目标是解决高频、易错、可量化的问题而不是做一个大而全的HR套件。系统上线后团队用得舒服才是第一目标。第一版把核心闭环跑通后面再按真实反馈迭代这个节奏最稳。2. 模块拆解五个业务闭环撑起完整的人员管理需求边界定下来之后我开始拆模块。人员管理系统说白了就是围绕“人”这个实体的信息流转需要把每个环节的状态和操作理顺否则做出来的只是一堆填表单页面撑不起实际业务。2.1 组织架构是最容易被低估的地基大多数开发拿到需求第一反应是做员工表把所有字段塞进去。但我把组织架构提到最前面。为什么因为员工表里的dept_id不只是一个外键它决定了权限范围、报表维度、考勤归属是整个系统的逻辑起点。组织架构用树形结构部门支持无限层级比如“总公司-华东分公司-上海一部”。每个部门要有编码、负责人、排序。部门负责人这个字段很关键因为后面审批流里“直接主管”就是从负责人这里带出来的。部门还有一个状态位。有些公司会保留“已撤销”的部门用于历史数据关联不能直接物理删除。否则查询两年前离职员工时他的部门字段指向一个不存在的记录报表直接拉胯。2.2 员工状态机入职、转正、调动、离职不是四条孤立记录员工在系统里不是一条静态数据而是有生命周期的未入职、试用期、正式、停薪留职、离职每个状态之间有不同的流转路径。入职登记时员工处于“未入职”到了入职日自动转成“试用期”试用期结束转正状态变成“正式”调动可能涉及部门和岗位的变化但状态不变离职时状态变成“离职”档案仍然保留只是不再出现在在职列表里。还有一种情况是离职后再次入职这时候要生成一条新的入职记录但历史状态流水不能丢。这个状态机如果不在设计阶段理清楚后面写流程代码时会到处if-else越改越烂。正确做法是先把状态流转图画出来用一张状态变更记录表保存每次变化的痕迹而不是直接在员工表上改状态字段。谁在什么时间把谁从什么状态改到什么状态全部可查。2.3 考勤与假勤整个系统最容易产生纠纷的地方考勤模块要做好边界条件比功能本身多得多。首先是班次配置标准班是早九晚六有的部门是弹性工作制还有生产线是三班倒每个班次的迟到、早退、缺卡规则都不一样。然后是请假类型年假、事假、病假、调休、加班。每种假的计算单位不同有的按小时有的按天年假还有剩余额度审批流程也不一样。这些规则如果写死在代码里产品一换规则就得改代码正确做法是做成配置表把班次、假期类型、审批链全部交给HR在后台配置。我见过很多内部系统在考勤上翻车问题基本都是出在“人走流程走但数据不对账”。所以我坚持把考勤原始记录和审批结果分开存储一条请假记录如果没走完审批就不能参与考勤计算但审批日志还得留底。这样出了问题能还原是哪一步算错了。2.4 权限边界HR、主管、员工看到的数据完全不同人员管理系统的数据敏感度很高。员工手机号、身份证号、薪资数据不是所有人都应该看到。权限设计我直接采用RBAC模型角色分四类超级管理员、HR管理员、部门主管、普通员工。超级管理员管系统配置和账号HR管理员可以查看全量员工信息能做入转调离操作部门主管只能看本部门及下级部门的员工普通员工只能看自己的档案和考勤。同一个页面不同角色看到的字段和按钮不一样。比如花名册列表HR能看到手机号部门主管只能看到姓名、部门、岗位联系方式直接打码。数据权限比菜单权限更容易被忽略。很多系统只做了“这个菜单你能不能进”没做“你进去了能看到哪些数据”结果一个部门主管能查全公司员工这是很严重的数据泄漏隐患。3. 数据库这样设计才能支撑组织调整和历史追溯业务模块理清楚之后数据库设计就顺理成章了。这个系统的核心表不多但每一张的字段取舍都直接影响后续开发效率。我依次列出自己最终采用的表结构并解释每张表为什么这么设计。3.1 部门表用parent_id撑起一棵可无限扩展的组织树部门表不需要做得太复杂核心字段就够用CREATE TABLE org_department ( id bigint NOT NULL AUTO_INCREMENT, parent_id bigint NOT NULL DEFAULT 0 COMMENT 上级部门ID0为根节点, dept_code varchar(32) NOT NULL COMMENT 部门编码, dept_name varchar(64) NOT NULL COMMENT 部门名称, leader_id bigint DEFAULT NULL COMMENT 部门负责人员工ID, sort_order int NOT NULL DEFAULT 0 COMMENT 排序号, status tinyint NOT NULL DEFAULT 1 COMMENT 1启用 0停用, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_parent_id (parent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;有人会问为什么不用左右值编码或者物化路径因为部门的数据量级通常只有几十到几百条parent_id加上递归查询足够应对。用MyBatis-Plus可以一次性查出全部门列表在Java内存里构建树没必要引入复杂方案。部门表还有个隐藏角色权限过滤。后续部门主管查看本部门数据时需要根据parent_id向下递归出所有子部门ID集合再对员工表的dept_id做in查询。3.2 员工表可变信息和静态信息要分清楚员工表是系统的主表但并不是字段越多越好。我把字段分成三类静态档案、在职信息、敏感信息。CREATE TABLE employee ( id bigint NOT NULL AUTO_INCREMENT, emp_no varchar(20) NOT NULL COMMENT 工号, name varchar(50) NOT NULL, gender tinyint DEFAULT NULL COMMENT 1男 2女, id_card varchar(128) DEFAULT NULL COMMENT 身份证号加密存储, phone varchar(20) DEFAULT NULL, email varchar(100) DEFAULT NULL, birth_date date DEFAULT NULL, hire_date date DEFAULT NULL COMMENT 入职日期, status tinyint NOT NULL DEFAULT 1 COMMENT 1试用 2正式 3停薪留职 4离职, dept_id bigint DEFAULT NULL COMMENT 当前部门, position_id bigint DEFAULT NULL COMMENT 岗位ID, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_emp_no (emp_no), KEY idx_name (name), KEY idx_dept_id (dept_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;静态档案姓名、性别、身份证号、出生日期这些基本不变。在职信息部门、岗位、入职日期、状态这些会变化。敏感信息身份证号绝对不能明文存我在接口层做了AES加密列表页展示时只显示前六位加后四位。手机号虽然没有身份证号那么敏感但导出功能里也做了脱敏处理。员工状态这个字段我特意没有用“在职/离职”这种二元值而是保留了“试用”“正式”“停薪留职”等状态因为考勤、薪资计算、报表统计都会依赖这个状态做条件过滤。3.3 状态变更流水表离职、再入职、调岗都要可追溯有了员工表为什么还要单独做一张状态变更流水表因为业务上经常需要回答这类问题这个人什么时候转正的中间有没有调过部门离职之后有没有再入职。如果只在employee表上更新状态这些历史就丢了。CREATE TABLE employee_status_log ( id bigint NOT NULL AUTO_INCREMENT, employee_id bigint NOT NULL, old_status tinyint DEFAULT NULL, new_status tinyint NOT NULL, change_type varchar(20) NOT NULL COMMENT 入职/转正/调动/离职/再入职, old_dept_id bigint DEFAULT NULL, new_dept_id bigint DEFAULT NULL, change_time datetime NOT NULL, operator_id bigint DEFAULT NULL COMMENT 操作人用户ID, remark varchar(255) DEFAULT NULL, PRIMARY KEY (id), KEY idx_employee_id (employee_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;每次员工状态变化或部门调动都写一条流水。比如转正操作old_status1, new_status2, change_type转正调岗操作old_dept_id和new_dept_id分别记录原部门和现部门。这张表还能顺便解决“离职率统计”的问题按change_type离职和时间区间分组统计数据来源不再靠人工数台账。3.4 考勤与审批表业务流水与主数据分离考勤相关表我单独拆开不跟员工主表混在一起。两个核心表考勤记录表和请假审批表。考勤记录表每天每个员工一行记录上下班时间、班次ID、迟到/早退/缺卡标记。这张表数据量增长最快我按月份做了分区同时保留一个sync_status字段标记这条记录是从考勤机同步过来的还是HR手工补录的避免对账时出现口径冲突。请假审批表保存的是“业务单据”谁申请的、请假类型、开始时间、结束时间、审批状态。审批完成后定时任务会把通过的假单换算成考勤结果更新到当天的考勤记录里。这里关键一点是审批状态不要直接存中文用数字枚举因为后续可能出现多级审批状态流转会更多。4. 技术选型与核心接口落地一个人也能守住全栈技术选型没有绝对标准关键看团队规模和维护成本。这套系统从头到尾是我一个人开发所以选了最主流、社区资料最丰富的一套组合确保后续接手的人也能快速上手。4.1 为什么选Spring Boot Vue3而不是更重的企业框架后端用Spring Boot 2.7 MyBatis-Plus 3.5 MySQL 8.0缓存用了Redis主要存验证码和登录Token。鉴权框架没有用Spring Security而是用了Sa-Token。很多人可能对Sa-Token陌生但它相比Spring Security最大的优势是轻量和直观登录、踢人、权限校验都是几行代码的事文档也清楚特别适合中小型单体项目。前端用Vue3 Element Plus Vite。选这套不是因为它最新而是因为Element Plus的表格、表单、弹窗组件非常成熟做后台管理系统基本是“搬砖”不需要自己造轮子。为什么不选更重的企业框架比如Activiti工作流或者Spring Cloud微服务原因是这个系统并发量和数据量都很小单体架构完全扛得住。引入微服务带来的部署复杂度对于一个人维护的项目来说反而是灾难。同理审批流第一版也没上Activiti直接做了个简单的“申请人提交-主管审批-HR确认”的单链路审批用一个流程配置表控制。4.2 RBAC权限模型菜单权限和数据权限分别怎么控制权限表一共四张用户表、角色表、用户角色关联表、角色权限表。用户和员工是分开的员工表管档案用户表管登录。员工入职时系统自动创建一个默认用户初始密码是手机号后六位首次登录强制修改。菜单权限用权限码控制。后端接口上用SaCheckPermission(employee:list)这样的注解如果当前用户没有对应权限码接口直接返回403。前端根据登录接口返回的权限码列表用v-if控制按钮显示隐藏。这里有个经验前端隐藏只是体验优化真正的权限校验必须放在后端接口上否则别人直接调接口就能绕过限制。数据权限是这套系统里最容易被忽略但也最重要的部分。我实现了一个MyBatis-Plus的DataScopeInterceptor在SQL执行前自动拼装数据权限条件public class DataScopeInterceptor extends JsqParserOptimize { // 伪代码示意根据当前用户的数据范围自动拼接 dept_id in (...) 条件 if (dataScope SCOPE_DEPT_AND_CHILDREN) { ListLong deptIds getDeptAndChildren(deptId); sql AND dept_id IN ( StringUtils.join(deptIds, ,) ); } }这样每个查询接口不用手动去判断数据权限拦截器统一处理出错概率大大降低。部门主管登录后即使代码里只写了“查询全部员工”实际执行SQL也会自动多出dept_id的过滤条件。4.3 员工列表接口一次带权限过滤的分页查询员工列表是整个系统最核心的查询接口我贴一段简化后的Controller示例方便说明接口层的组织方式SaCheckPermission(employee:list) GetMapping(/employee/page) public ResultPageEmployeeVO page(EmployeeQuery query) { PageEmployee page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperEmployee wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(query.getName()), Employee::getName, query.getName()) .eq(query.getDeptId() ! null, Employee::getDeptId, query.getDeptId()) .eq(query.getStatus() ! null, Employee::getStatus, query.getStatus()) .orderByDesc(Employee::getCreateTime); employeeService.page(page, wrapper); // 转VO对身份证号、手机号脱敏 PageEmployeeVO voPage convertToVO(page); return Result.ok(voPage); }查询条件用MyBatis-Plus的LambdaQueryWrapper动态拼接不需要手写XML。条数超过几千条时SQL直接走组合索引idx_dept_id和idx_name性能没有压力。返回给前端的VO对象会做字段脱敏防止敏感信息直接暴露在接口响应里。5. 数据迁移把320人的Excel台账安全搬进新系统系统开发完成只是第一步真正让HR部门对系统建立信任的是数据迁移那一天。如果导进去的数据是错的后面所有功能都会被质疑。所以数据迁移我单独当成一个项目来做前后花了一周比写某些模块还费时间。5.1 清洗数据手机号、身份证、重名三类高频脏数据从Excel导入前必须写一个清洗脚本把三类脏数据先处理掉。手机号统一去空格、去横线、去括号然后正则校验^1[3-9]\d{9}$。校验不通过的行单独记到错误清单不直接进库。身份证号15位的老身份证先转成18位校验最后一位校验码。这里要注意身份证号不仅是格式问题还涉及出生日期和性别的自动填充。如果身份证号和Excel里填的出生日期不一致以身份证为准并记录下来后续人工复核。重名同一个姓名出现了多条记录不能盲目合并也不能直接跳过。我用“姓名身份证号后四位手机号”做组合匹配完全匹配的认定为同一人只能匹配到姓名但手机号不同的放进人工复核清单由HR判断是否同一人。总之清洗脚本只做“能自动处理的自动处理不能自动处理的绝不自动猜”。5.2 分批导入与失败回滚宁可慢不能乱清洗完成之后正式导入我用的策略是每次读取50条开启一个事务成功50条提交一次任何一条失败则回滚当前批次并记录失败原因到导入日志表。Transactional(rollbackFor Exception.class) public void importBatch(ListEmployeeImportDTO batch) { for (EmployeeImportDTO dto : batch) { Employee employee convert(dto); employeeMapper.insert(employee); // 生成员工ID employeeStatusLogMapper.insert(buildLog(employee, 入职)); } }为什么不用大事务一次性导入320条主要是为了安全。如果第300条数据有问题回滚全部前面已经成功的数据也得重新导入很浪费时间。分批提交虽然慢一点但错误的影响范围被限制在50条以内。导入完成后程序自动生成一份导入报告包含成功条数、失败条数、每条失败的具体原因HR可以对照报告去改原表。Excel文件读取用的是EasyExcel避免直接用POI的XSSFWorkbook一次性加载整个文件导致内存溢出。320人的文件不大但如果是后续几千人的迁移这个选择就很有必要了。5.3 迁移后的验收用SQL和Excel做双盲核对导入完成不代表迁移结束还差最后一步验收。我用两个维度做核对。第一维度是总数。Excel原始花名册320人数据库员工表也是320人两边一致。但总数一致不一定每条都一致所以还要分部门统计比如技术部Excel是45人数据库里也要是45人这样能发现有人被导错部门了。第二维度是抽样明细。我从每个部门随机抽2-3个人总共抽了30个人逐一核对姓名、手机号、部门、状态是否和Excel一致。核对完再让HR自己抽10个人验一遍两边抽查结果一致才敢正式宣布迁移完成。这个双盲核对过程虽然枯燥但非常必要。系统刚上线时数据准确率比功能完整度更重要。第一印象一旦是“系统数据不准”后面再怎么优化用户的信任都很难建立。6. 上线三个月后的复盘这些坑比功能本身更值得记录系统上线三个月整体稳定但中间也踩了几个坑。这些坑在需求阶段很难预判只能在实际运行中暴露。我把它们记录下来希望对做同类系统的同学有帮助。6.1 组织架构要有快照否则历史数据会失真第一个坑出在部门调整。公司把市场部拆成了品牌部和渠道部员工表里的dept_id全部更新了。结果月底做离职率分析时发现本月离职统计里所有标注“市场部”的员工全部消失了因为他们现在的部门是品牌部或渠道部。问题出在员工状态流水表只记录了dept_id的变化但没有记录部门名称的快照。如果只看当前dept_id历史部门归属完全没法还原。后来的解决方案是在流水表里增加old_dept_name和new_dept_name两个冗余字段部门调整时顺便更新历史记录的部门名称。虽然违反了所谓“第三范式”但业务上必须这么做否则历史报表没法做。6.2 考勤边界条件跨天、请假与加班重叠规则要前置考勤模块上线第二周就遇到一个工单产线员工上晚班晚上十点打卡上班第二天凌晨两点打卡下班系统全给算成了缺卡。原因是我用的是自然日计算打卡时间没有处理跨天班次。类似的边界条件还有一堆请假从昨天下午到今天上午怎么办加班时长和请假时长重叠怎么算弹性班次员工晚到一小时但晚走一小时算不算迟到。这些东西在需求访谈时很难被HR主动提出来但他们心里其实默认系统应该“知道”。我的教训是考勤模块上线前一定要让HR整理一份常见异常场景清单至少覆盖跨天、缺卡、迟到、早退、请假重叠、加班调休这六类。开发时把这些场景作为测试用例提前写进去而不是等上线后让用户当测试员。6.3 导出功能也要过权限关数据安全不能留死角权限控制做得再细如果导出功能没跟上等于白做。我见过太多内部系统列表页把手机号打码了但点“导出Excel”之后全量手机号和身份证号都在文件里任何有导出权限的人都能带走。这个坑我差点也踩了。幸好上线前的安全自查里发现HR用的导出接口直接查了全字段没有考虑调用人角色。后来我把导出接口改成复用列表查询的数据权限逻辑部门主管导出时数据范围限制在本部门及下级普通HR导出需要填写导出理由并且所有导出操作都写入审计日志记录谁在什么时间导出了多少条数据。数据泄漏这种事不怕一万就怕万一审计日志至少能在事后追责。6.4 Excel导出优化EasyExcel替代手写POI内存直接降下来最后一个坑是技术性的。最初做导出功能图省事直接用POI的XSSFWorkbook把所有数据放在内存里再写文件。测试时几百条数据没问题后来导出全量320人也没感觉但到了月底HR导三个月考勤明细一万多条记录直接让应用内存飙到700MB差点把服务搞崩。后来换成了EasyExcel它基于SAX模式流式读写不会一次性把所有数据加载到内存。同样一万条记录导出内存占用降到了100MB以内。而且EasyExcel的注解模型比POI手写样式简单太多ExcelProperty(工号) private String empNo; ExcelProperty(姓名) private String name;下载文件名也踩了个小坑中文文件名直接用response.setHeader会乱码必须用URLEncoder.encode(fileName, UTF-8)处理后再拼到Content-Disposition里。这套系统从立项到稳定运行前后大概三个月。如果让我总结最值得分享的一条经验就是自研系统的核心从来不是技术栈多新、架构多复杂而是把Excel时代没说清的规则一件件变成代码和数据表。人事部之前最怕月底对账现在打开系统点一下就能看到各部门在职人数、年龄结构、离职率老板再问“这个季度市场部走了几个人”HR两秒钟就能给出答案。这种“被看见”的价值比任何炫酷功能都实在。本文还有配套的精品资源点击获取