Pinxian Li上个月跟一个做HR系统的朋友吃饭，他吐槽了一件事：公司三十多个部门、两千多号人，花名册至今靠Excel在钉钉群里传来传去。离职的员工还在表格里占着一行，新员工的入职时间经常被手滑改错，更别说组织架构调整后部门归属全乱套。我当时就说，这种规模的企业，与其反复去买SaaS账号、跟供应商反复拉锯需求，不如基于Spring Boot从零搭一个内部员工管理系统，顺手还能把权限、导入导出、数据统计都管起来。
这篇内容就把完整的设计和实现过程拆开讲。项目代号里的_8rxd27hj只是平台生成的归档ID，不影响功能。你真正拿到的是一套完整可运行的员工管理后台，核心覆盖了登录鉴权、部门树、员工信息维护、Excel批量导入导出、文件上传、操作日志等模块。适合正在做毕设或课设的学生，也适合刚入职想用Spring Boot练手的中级开发者——整体代码量不大，但链路完整，是理解企业级后台开发套路的一个很好的切入点。
1. 为什么还要自研员工管理系统：Excel、Outlook与现代企业的撕裂
很多人在看到“企业员工管理”这几个字时，第一反应是市面上不是有飞书、钉钉、企业微信吗？为什么还要自己写一套。这个疑问很正常，但实际情况远比想象中复杂。
1.1 一个典型业务场景：HR月底的Excel灾难
我见过一家做连锁零售的企业，员工分布在四十多家门店，总部HR每个月要做三件事：汇总各门店发来的考勤表、核对入职离职名单、给财务提供工资核算底表。三个表格式各不相同，有的门店用Excel 2003的.xls格式，有的用WPS导出的.et，有的直接在邮件正文里贴一段表格。结果是什么？每个月至少有两天，HR部门的两个小姑娘什么正事都不干，就拿着手机在群里一个个核对哪份表是最新版本。
这种痛苦的本质是：员工数据不是一条记录，而是一个持续变化的状态流。入职、转正、调岗、离职、重新入职，每一个动作都会影响数据的准确性。Excel是个好工具，但它没有“主数据”的概念，同一个员工在A表叫“张三”,在B表叫“张 三”，在C表里手机号是隐藏的，系统根本没法自动关联。
1.2 项目边界：哪些功能必须做，哪些可以留到二期
如果你去问业务方，他们会说出二十个功能需求，甚至包括“HR想给员工发生日祝福短信”。但作为设计者，你要做的第一件事是划定MVP边界。基于Spring Boot的这套员工管理系统，我最终圈定的核心功能就五块：
- 组织架构管理：部门的增删改查、层级关系、状态启用停用。
- 员工信息管理：基本资料、联系方式、学历、工作经历、入职离职状态。
- 用户与权限：登录认证、角色区分（管理员、HR、普通员工）、菜单权限控制。
- 批量数据操作：Excel模板下载、批量导入、批量导出，这是HR最刚需的功能。
- 统一检索与操作留痕：按姓名/部门/状态检索，所有增删改操作写入日志。
这五块逻辑上闭环：先有部门，再往部门里塞员工，员工登录系统后再看自己的信息，管理员维护一切。至于考勤打卡、薪资计算、绩效考核这类重型业务，坚决不碰——它们技术上不复杂，但业务规则千差万别，硬塞进来只会拖垮主流程。
1.3 给同类项目的一句话定位
这套系统的定位是“企业内部主数据管理平台”，它的核心不是炫技，而是把一摊散落在各处的员工数据收拢成一份真相。Spring Boot在这里的价值不是魔法，而是一个成熟的、约定优于配置的底座，把Web开发里最繁琐的配置工作替你干掉了大半，让开发者能把精力集中在业务逻辑本身。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型的底层逻辑：Spring Boot 3.x、MyBatis-Plus与鉴权方案的权衡
技术选型这部分，我最想强调的是：不要为了用新技术而用新技术，每一项选择都应该有明确的理由。下面把这些理由一条条说清楚。
2.1 为什么是Spring Boot而非SSH或SSM
十年前做这种系统，主流方案是Spring MVC + Spring + MyBatis（SSM），再早一点是SSH（Spring + Struts2 + Hibernate）。SSM的问题不在框架本身，而在配置地狱：web.xml、spring-mvc.xml、mybatis-config.xml、数据源配置、事务配置、扫描配置，光配置文件就有七八个，任何一个写错都能消耗半天时间。
Spring Boot把这一切压缩成“一个启动类 + 一个application.yml”。它做的事情本质上是自动配置：你引入了spring-boot-starter-web，它自动帮你装配好DispatcherServlet、内嵌Tomcat、JSON序列化器；你引入了mybatis-plus-boot-starter，它自动帮你扫描Mapper接口。你不需要理解每一个自动配置的细节，但你要知道去哪看：spring-boot-autoconfigure包下的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里列出了所有自动配置类的清单。
提示：Spring Boot 4.0之后，自动配置的注册方式又有调整，
DataSourceAutoConfiguration等核心类的包路径也发生了变化。如果将来升级版本时发现数据源配置不生效，优先检查这个imports文件里的实际配置类路径，别在application.yml里死磕。
2.2 版本选择的坑：直接用3.x还是继续用2.x
做这个项目时，我面临一个现实选择：是选成熟的Spring Boot 2.7还是直接上3.x。我的结论是：新项目直接上3.x。
原因有三个。第一，Spring Boot 2.x在2023年之后社区维护力度明显下降，很多依赖的版本开始不兼容。第二，3.x基于Jakarta EE 9+规范，包名从javax.*改为jakarta.*，虽然迁移时有点疼，但这已经是Java生态的既定方向。第三，3.x内置的Spring Framework 6.0对AOT编译、虚拟线程等新特性支持更好。
但3.x也有坑，最典型的就是jdk版本要求——必须JDK 17以上。如果你们的开发环境还在用JDK 8，那不用犹豫，老老实实用2.7.x。我见过太多人项目代码写得挺漂亮，结果公司统一打包环境还是JDK 8，部署时直接编译失败。
另外，3.x里如果遇到Jackson的JsonMapper$Builder相关报错，不要慌，这通常是因为Spring Boot 3.x内置的Jackson版本与项目中手动引入的jackson-databind版本冲突。解决办法是统一依赖版本，或者干脆删除手动引入的Jackson依赖，交给Spring Boot的BOM管理。
2.3 ORM选型：MyBatis-Plus还是Spring Data JPA
这是网上争论最多的话题之一。我个人的选择是MyBatis-Plus，理由非常务实：
- 项目里有大量的多表查询、复杂SQL，MyBatis的XML写法让我对最终执行的SQL有完全控制权。
- 单表CRUD由MyBatis-Plus的
BaseMapper和IService直接提供，代码量能减少一半以上。比如分页查询，一个Page对象传进去就完事。 - 团队里如果有人不熟悉Hibernate的缓存机制，用JPA很容易写出性能很差的查询而不自知。
当然，Spring Data JPA也有它的优势：领域驱动设计友好、方法名推导查询非常简洁、实体生命周期管理完善。如果你的项目是全新的、表结构相对简单、团队对JPA有经验，选JPA完全没问题。怕就怕在“一半MyBatis一半JPA”的混搭系统，那才是真正的维护灾难。
2.4 鉴权方案：JWT轻量方案与Sa-Token的取舍
员工管理系统的鉴权需求不算复杂：登录后签发凭证，后续请求带上凭证，后端校验身份和角色。最经典的方案是Spring Security + JWT，但说实话，Spring Security默认自带的那套登录页、Session管理，对前后端分离的系统来说反而多余，配置起来也比较绕。
我最后选了Sa-Token。这不是广告，Sa-Token的学习成本比Spring Security低一个量级，登录就是一行StpUtil.login(userId)，登出就是一行StpUtil.logout()，想要踢人下线、记住我、同端互斥登录，都有现成API。底层用的也是Token机制，可以自定义Token风格，前后端分离场景下非常顺手。
具体链路是这样的：
- 前端登录，后端校验用户名密码（密码用BCrypt加密存储）。
- 校验成功后
StpUtil.login(userId)，框架自动生成Token返回给前端。 - 前端把Token存在请求头（如
satoken）里，每次请求带上。 - 后端配置Sa-Token拦截器，解析Token并填充当前登录用户上下文（用
StpUtil.getLoginId()读取）。 - 角色权限控制用注解
@SaCheckPermission("employee:add")，在Controller方法上加注解即可。
这套方案的优点是完全无状态，不依赖Session，方便未来横向扩展。缺点大家也都知道：Token无法在服务端主动失效（除非引入Redis存黑名单），所以如果对安全性有极苛刻要求，可以考虑Sa-Token的集成Redis方案，把Token状态同步到Redis统一管理。
3. 数据库设计：员工、部门、账号三张核心表如何建模
数据库设计是这类管理系统的地基。很多新手一上来就建一张大宽表，把员工的所有字段都塞进去，结果业务一跑起来就发现问题不断。这里讲讲建模时要考虑的点和最终落地的表结构。
3.1 表结构设计的四个前提
设计之前，想清楚四个问题：
第一，员工和组织架构是什么关系？一个员工只能属于一个部门吗？实际上员工可能兼职多个部门，但MVP阶段可以先做单归属，用“所属部门ID”字段表示，后续要扩展多归属再建关联表。