先把结论放前面：这套 SpringBoot + Vue + MyBatis + MySQL 的人事管理系统，是这一两年我见到过的中小型企业管理类项目里，结构和完整度都比较稳的一套。员工档案、部门岗位、考勤请假、薪资核算、公告通知、角色权限，该有的人事模块全都有，而且不是那种只搭了壳子的演示项目，核心业务逻辑是能直接落地的。无论你是刚学完 SpringBoot 和 Vue 想找一个完整项目练手，还是所在团队需要一个能二次开发的人事系统底座，这套源码都值得仔细过一遍。
我按自己的理解把整个项目从需求、数据库设计、后端实现、前端联调到实际部署遇到的问题，完整拆开讲一遍。中间会穿插一些我在类似项目里踩过的坑和总结出来的经验，读的时候可以对照自己的实际情况。
1. 项目全景：企业人事系统的需求与架构选择
1.1 先搞清楚：人事管理系统到底要管哪些事
很多新手拿到这类项目第一反应是"不就是增删改查吗"，这话对了一半。增删改查是形式，真正难的是人事业务的特殊约束。就拿员工入职来说，不是往表里插一条记录就完了：入职触发账号创建，账号绑定角色，角色决定权限，员工归属部门，部门隶属组织树，而组织树又影响审批链路的走向。一个看似简单的操作，背后是一条完整的数据链条。
这套系统的业务边界划分得很清楚，核心模块包括：
- 员工信息管理：入职、调动、离职全流程，维护员工基础档案、联系方式、学历、合同信息。
- 组织架构管理：部门树、岗位体系，支持多级部门层级和岗位调动记录。
- 考勤管理：上下班打卡记录、请假申请、加班登记，并且能汇总成月度考勤报表。
- 薪资管理：根据考勤数据、岗位工资、社保公积金等规则核算月度薪资，生成工资条。
- 公告通知：内部通知发布与查看范围控制。
- 系统管理：用户、角色、菜单权限这三件套是标准配置。
这个模块划分基本覆盖了中小企业人事部门 80% 以上的日常事务。作为一套参考项目，它的价值在于把真实业务流转的链路完整呈现了出来，而不是每个模块各自为政。
1.2 技术栈选型为什么锁定这四件套
SpringBoot + Vue + MyBatis + MySQL 这个组合在企业项目里的出场率非常高，选择它不是因为新潮，而是因为稳。SpringBoot 解决了传统 SSM 项目大量 XML 配置的痛点，内嵌 Tomcat 让部署变成了"一个 jar 包跑起来"；Vue 在前端组件化和数据驱动方面的开发效率明显优于传统 jQuery 方式；MyBatis 作为轻量级持久层框架，对复杂 SQL 的把控力很强，适合人事系统里大量关联查询和报表统计的场景；MySQL 则是团队上手成本最低的关系型数据库，稳定性和生态都没得挑。
有人会问为什么不用 JPA 或者 MyBatis-Plus。这种选型差异在真实项目里确实存在，但 MyBatis 在这种管理系统中有一个不可替代的优势：SQL 是显式可控的。人事系统里有大量多表关联、条件动态拼接的统计查询，MyBatis 的 XML 里写出来的每一句 SQL 都是透明的，出了问题直接就能排查，而 JPA 生成的复杂查询一旦性能出现问题，排查成本会成倍上升。MyBatis-Plus 在单表操作上确实省事，但这套项目里嵌套查询和关联统计太多，原生 MyBatis 加手写 SQL 反而更清晰。
前端没有选择重型框架，就是 Vue 2 加 Element UI，配合 Vue Router 和 Vuex 做路由与状态管理。这套组合在管理后台领域可以用"经典"来形容，社区资料多、组件完善，遇到问题搜一下基本都有答案。
1.3 模块拆分与整体功能地图
从代码结构上看，项目采用前后端分离，后端按功能模块分包，前端按页面视图组织。整体功能地图可以归纳为三个层次：
第一层是基础数据层，包括部门、岗位、员工档案这类静态数据，它们是整个系统的数据基石。第二层是业务流转层，包括请假审批、入职离职流程、考勤打卡等动态业务，这一层依赖基础数据，同时产生过程数据。第三层是统计分析层，包括薪资报表、考勤汇总、人事统计，这一层对前两层的数据做聚合加工。
这个分层思路值得新人在自己设计系统时借鉴。我见过不少项目把员工信息和考勤记录混在一起写，后来统计报表的时候被迫写出一堆冗余查询。这套项目的分层方式能从源头上避免这个问题，数据库设计时就把数据归属理清楚，后续写业务代码会顺畅很多。
2. 数据库设计与核心表结构实操
2.1 从员工信息表开始的10张核心表设计
数据库是这套系统最值得研究的部分，因为人事系统的表关联复杂度集中在组织架构和业务流转上。项目核心表大概有这些：员工表、部门表、岗位表、考勤记录表、请假申请表、加班登记表、薪资表、工资条明细表、公告表、用户表、角色表、菜单权限表。单看数量不算多，但每张表之间的关系需要仔细设计。
拿员工表来说，设计时要注意几个细节。员工编号建议用业务编码，比如入职年份加序号，而不是自增主键直接暴露给用户。部门 ID 和岗位 ID 作为外键关联到对应表，但为了查询效率，员工表里也会冗余存储部门名称和岗位名称，这样列表页展示时不需要每行都关联查询。入职时间和离职时间分开存储，通过一个状态字段区分在职、离职、试用期等状态，这个状态字段是很多业务查询的过滤条件，必须加索引。
我在实际开发中惯用的做法是每张表都保留创建时间、更新时间、创建人等通用字段，并设置一个逻辑删除标记。这套项目也是这么处理的，逻辑删除比物理删除安全得多，尤其是员工档案这种需要追溯历史的数据，误删之后恢复成本极高。
2.2 部门与岗位的多层级组织架构建模
部门树是人事系统里最容易设计失误的地方。最简单的方案是只存一个 parent_id 字段，但一旦部门层级深了，查询某个部门下所有子部门就非常痛苦。这套项目采用的是经典的父 ID 递归方案：部门表包含 dept_id、parent_id、dept_name、排序字段等，配合后端递归查询拼装成树结构。
这个方案的好处是数据建模简单，树的层级关系直观，新增和移动部门只需要改一个字段。缺点是查询子孙部门需要递归遍历，在部门数量很大的时候性能会下降。不过对于中小企业的组织规模，这个方案完全够用，代码里递归查询的深度控制在三层以内，配合缓存机制，实测下来接口响应速度是没问题的。
岗位表设计相对简单，岗位名称、岗位编码、所属部门、岗位级别是核心字段。这里要特别注意一个概念：岗位和部门不是一对一关系，同一个部门可以有多个岗位，同一个岗位也可能被不同部门使用。所以岗位表里建议单独维护所属部门字段，不要把岗位设计成挂在某个部门下的子表，否则后续员工调岗时数据维护会很麻烦。
2.3 考勤请假与薪资计算的表关联逻辑
考勤和请假这两块是人事系统里数据量增长最快的部分，设计时就要考虑查询压力。考勤记录表按天存储每个员工的打卡数据，包含上班打卡时间、下班打卡时间、考勤状态等字段。请假申请表存储每次请假的信息，包括请假类型、开始时间、结束时间、请假时长、审批状态。
这里有个很关键的关联逻辑：薪资核算时需要同时读取考勤汇总和请假记录。比如当月请假超过一定天数，就要按比例扣减绩效工资；加班时长超过阈值，需要计算加班费。这套系统的薪资表设计是把每月每个员工的薪资核算结果存成一条记录，同时保留考勤汇总快照字段，比如出勤天数、请假天数、加班时长直接冗余在薪资表里。
这种"计算结果冗余存储"的方式是我比较推荐的。有些设计会在每次查看工资条时临时计算当月薪资，看似省存储，实际上只要考勤数据有变动，计算逻辑就要重跑一遍，出错的概率大得多。每月定时核算一次，把结果固化成记录，后续查询和报表都直接读取，稳定且高效。
3. 后端SpringBoot+MyBatis接口实现要点
3.1 分层架构与项目目录组织方式
后端代码采用经典的四层架构：Controller 层负责接收请求和参数校验，Service 层处理业务逻辑，Mapper 层通过 MyBatis 与数据库交互，Entity 层定义数据实体。项目目录按功能模块划分，而不是按技术分层划分，这一点很多人容易搞混。也就是说，先按 employee、department、attendance、salary 等模块建包，每个包内部再分 controller、service、mapper、entity 子包。
这样做的好处是聚合度高，修改一个功能时所有相关代码都在同一个包内，导航成本低。如果反过来按技术分层，所有 Controller 堆在一个包、所有 Service 堆在另一个包，项目大了之后找代码会非常痛苦。这套项目虽然规模不算大，但目录组织方式是按照可扩展的标准来的，这点很加分。
统一的返回格式也是后端设计里容易被忽略但极其重要的细节。项目里定义了一个通用响应类，包含状态码、消息、数据三个字段，所有接口统一返回这个结构。前端 axios 拦截器统一处理这个结构，成功时取数据，失败时弹错误提示。这样做避免了每个接口各写各的返回格式，前端处理逻辑也能统一。
3.2 MyBatis xml映射与动态SQL使用经验
MyBatis 的核心使用场景是把复杂 SQL 写在 XML 里，这套项目在员工列表查询上把这个玩得很透。员工列表需要支持多条件组合过滤：部门、岗位、状态、入职时间范围、关键字搜索，这些条件可能同时生效也可能一个都没有。用 MyBatis 的动态 SQL 可以优雅地解决，核心是<where>标签加<if>标签的组合。
<select id="selectEmployeeList" resultType="com.example.entity.Employee"> SELECT e.*, d.dept_name, p.position_name FROM employee e LEFT JOIN department d ON e.dept_id = d.dept_id LEFT JOIN position p ON e.position_id = p.position_id <where> <if test="deptId != null"> AND e.dept_id = #{deptId} </if> <if test="status != null"> AND e.status = #{status} </if> <if test="keyword != null and keyword != ''"> AND (e.emp_name LIKE CONCAT('%', #{keyword}, '%') OR e.emp_no LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY e.create_time DESC </select>用<where>标签而不是手写 WHERE 1=1 是个好习惯，它会在条件成立时自动添加 WHERE 关键字，并且会去除第一条条件前面多余的 AND。手写 WHERE 1=1 虽然也能跑，但在 SQL 日志里看着不专业，而且有些数据库优化器对这种方式会有额外的解析开销。
LIKE 查询这里用 CONCAT 拼接，而不是直接在 XML 里写#{keyword}%，原因是为了防止 SQL 注入。虽然 MyBatis 预编译机制本身能防注入，但养成把参数都放进 #{} 的习惯，不要用 ${} 拼接字符串，这是我在项目 review 时一定会检查的点。
分页处理也是 MyBatis 使用里的重点。这套项目用 PageHelper 插件实现物理分页，用法是在查询前调用 PageHelper.startPage(pageNum, pageSize)，后面紧跟的查询就会自动拼接 LIMIT 语句。这里有个容易踩的坑：PageHelper 只对紧接着的下一条 SQL 生效，中间不能插其他查询，否则分页会作用到错误的语句上。
3.3 登录认证与权限拦截的完整实现
人事系统的权限控制比一般系统更敏感，员工的薪资数据、个人档案都属于敏感信息，不能随便一个账号都能查看。这套项目采用的是经典的 JWT Token 认证加 Spring 拦截器做统一鉴权。
登录流程是：用户提交账号密码，后端校验通过后生成一个 Token，Token 里携带用户 ID 和用户名，有效期设置为 24 小时。前端拿到 Token 后存储在本地，每次请求在请求头里带上 Authorization 字段。后端写了一个拦截器，对所有需要认证的接口统一校验 Token，解析失败或过期直接返回 401。
权限这块用了 RBAC 模型，也就是用户绑定角色、角色绑定菜单权限。登录时后端查询用户拥有的角色和权限集合，返回给前端，前端根据权限数据动态渲染菜单，没有权限的菜单直接不显示。后端接口层面也做了控制，每个接口上的权限标识符和用户权限集合匹配，不匹配就拦截。
这里要特别提醒一个我踩过的坑：前端隐藏菜单只能改善体验，不能作为安全手段。真正的权限控制必须落在后端接口层，因为前端代码是暴露在浏览器里的，任何人都能绕过页面直接调接口。这套项目后端的拦截器做得比较完整，我实测过直接带一个低权限用户的 Token 去请求敏感接口，会被正确拦截，这才算合格。
4. 前端Vue页面开发与联调指南
4.1 路由配置与页面骨架搭建
前端部分是基于 Vue CLI 创建的标准工程，路由用 Vue Router 的异步组件加载方式，也就是路由懒加载。这样首屏只加载必要资源，整个项目几十个页面，如果全部打包成一个文件，初次加载会非常慢。按路由拆包之后，每个页面独立的 js 文件按需加载，体感提升明显。
页面骨架是典型的管理后台布局：左侧菜单栏、顶部导航栏、中间内容区。菜单数据不是写死在前端的，而是登录后从后端接口读取，根据当前用户的权限动态生成。这个方案的优点在于权限调整不需要重新发布前端，后端改了角色菜单关联关系，用户下次登录看到的菜单就变了。
动态菜单的实现思路是路由先注册公共页面，然后根据后端返回的菜单数据递归生成组件路由。这里有个技巧：菜单表里的 component 字段存的是组件路径字符串，前端拿到后通过import()动态加载对应组件。我见过不少项目在这块图省事，把菜单写死在前端路由表里，后端只返回一个角色标识，前端再根据角色判断菜单显示，这种写法维护性其实很差，角色稍微多一点就会出现过多 if else 判断。
4.2 axios封装与接口对接细节
前端的接口请求统一走 axios 封装，这是管理后台项目里必须做的一件事。封装的核心内容包括三部分：基础 URL 配置、请求拦截器、响应拦截器。基础 URL 根据环境变量区分，开发环境指向本地后端，生产环境指向服务器地址，方便切换。
请求拦截器做两件事：一是从本地存储取出 Token 加到请求头，二是对所有请求做统一 loading 处理。响应拦截器的逻辑更关键：判断响应状态码，2xx 直接返回数据；业务状态码非 200 的，弹出错误提示；401 未认证的，清除本地登录信息并跳回登录页；网络异常的，提示用户检查网络。
我在联调过程中发现一个常见的坑：跨域配置。前后端分离项目开发时，前端跑在 8080，后端跑在 9090，浏览器默认会拦截跨域请求。后端解决方式是在配置类里注册跨域映射，允许指定来源地址访问，同时允许携带凭证。这里要注意前端端口变了，后端配置要同步改，否则就会出现"接口用 Postman 调没问题，页面里调就报跨域错误"的经典问题。
4.3 表格分页与表单校验的前端落地
管理后台最常见的页面组合就是顶部搜索表单、中间数据表格、底部翻页器，这套项目的员工列表页就是标准模板。分页数据的处理方式是：前端维护 pageNum 和 pageSize 两个参数，每次查询或翻页时重新请求接口，后端返回总条数和当前页数据，前端更新表格。
这里有个交互细节值得学习：搜索条件变更后要自动重置页码为 1，不然在第 5 页执行了一个筛选，数据变少了但页码还在 5，就会出现空白页。这个小逻辑很多新手容易漏，但这个项目里处理得正确。
表单校验用的是 Element UI 自带的校验规则。以员工新增表单为例，必填字段用 required 规则，手机号用正则校验，入职时间用日期范围约束。这里一个实用的经验是：前端校验规则里的正则表达式，要和后端校验保持一致。前后端校验不一致的情况我遇到太多次了，前端能过、后端报错，或者反过来，用户体验很差。最稳妥的做法是两边的规则都覆盖常见格式，比如手机号至少做长度和首位数字的验证。
5. 部署运行与常见问题排查实录
5.1 本地环境搭建与数据库初始化
把这个项目跑起来不需要太复杂的环境。后端要求 JDK 1.8 以上、Maven 3.6 以上；前端要求 Node.js 和 npm；数据库要求 MySQL 5.7 或 8.0。安装顺序建议是：先装 MySQL，再装 JDK 和 Maven，最后装 Node 环境。
数据库初始化是第一个容易出问题的地方。项目里提供了完整的 SQL 脚本，包含建库建表语句和初始数据。导入时注意选择正确的字符集，推荐 UTF-8，不然 Windows 环境下导入中文数据会变成乱码。执行方式很简单，用命令行或者数据库管理工具运行整个 SQL 文件即可。
后端配置文件里注意修改数据库连接信息，包括 URL 里的数据库名、用户名、密码。还有一个细节是时区配置，MySQL 8.0 要求连接串里加上 serverTimezone 参数，不写会报时区错误。这也是新手经常卡住的地方，看到这类报错不要慌，基本都是配置参数的问题。
前端启动前先执行 npm install 安装依赖，这个过程可能需要几分钟，视网络情况而定。安装完成后 npm run serve 启动开发服务器，默认端口 8080。浏览器访问后能打开登录页说明前端已经正常了。
5.2 前后端联调中最容易翻车的5个配置
我把这套项目和同类项目联调时出现频率最高的问题整理一下，基本是五个方面。
第一个是数据库连接失败，报 Communications link failure 之类的错误，九成是数据库没启动或者账号密码不对，先检查 MySQL 服务状态，再确认配置文件里的密码有没有填错。
第二个是端口冲突，后端启动时报 Port already in use。解决方案是找到占用进程并结束，或者在配置文件里换一个端口。前端代理的 target 地址也要同步改，不然转发不到正确端口。
第三个是跨域问题，浏览器控制台明确报 CORS 错误。这个属于配置问题，检查后端跨域配置的来源地址是否包含前端端口即可。
第四个是登录后请求不到用户信息，Token 明明发了但后端解析不出来。常见原因是请求头字段名不一致，比如后端要求 Authorization，前端封装 axios 时写成了 Token，对不上自然验签失败。
第五个是日期格式问题，前端传的日期字符串后端解析失败。解决方式是全局配置日期格式转换器，或者前端统一按 ISO 标准格式传参。这个坑很隐蔽，往往只有在特定日期操作时才会触发，排查起来比较费时间。
5.3 排查思路速查：从后端报错到前端白屏
实际排错的时候，我习惯于按照一个固定顺序来：先看后端日志，再看网络请求，最后才看前端代码。后端日志里通常会有完整的异常堆栈，定位最快的方式是搜索第一条 "Caused by"，它往往指向真正的问题根源，而不是表象。
网络请求面板是前后端联调时的利器。打开浏览器开发者工具的 Network 标签，查看某个请求的完整返回内容。如果是 500 错误，后端日志结合前端请求参数一起看，基本能还原问题全貌；如果是 404，检查后端路由和前端请求地址是否一致，这是最常见的低级错误；如果是 200 但页面没有数据，看一下响应体的数据结构，多半是前端取值字段名和后端返回字段名对不上。
前端白屏的问题我遇到过一个特别典型的案例：页面组件引用了不存在的属性，导致渲染报错，Vue 在开发模式下会提示具体错误位置，但生产模式下可能直接白屏。排查方式是打开控制台看报错信息，定位到具体组件行号。很多白屏问题的根源其实简单，只是大家习惯先怀疑后端，反而绕了远路。
6. 项目二次开发的三点建议
如果你打算在这套代码基础上接着做开发，我根据自己的实际经验给三点建议，能帮你少走弯路。
第一，业务扩展前先理清数据关系。人事系统的每次功能扩展几乎都会触碰原有表结构，比如新增一个"合同到期提醒"功能，可能要在员工表加合同到期日期字段，也可能要新建合同管理表。动手写代码之前，先画清楚数据关系，比直接改表更稳妥。数据库变更建议用版本化管理，每次变更生成一个增量 SQL 脚本，而不是直接在原表上改，这样后续部署和回滚都可控。
第二，报表统计功能要提前考虑性能。薪资汇总、考勤统计这类接口，数据量大了以后很考验 SQL 质量。如果发现某个统计接口响应变慢，优先检查是不是没有走索引，或者有没有在 SQL 里做了大范围的全表扫描。对于月度汇总这种固定时间范围的查询，给时间字段加索引是最直接的优化手段。
第三，尽量保留完整的操作日志。人事系统的数据敏感性决定了审计需求很强，谁在什么时间修改了员工的薪资信息，这些都需要有记录。这套项目里基础的操作日志已经有了，如果你做二次开发，建议把关键业务节点的日志粒度做得更细一些，不只是记录"谁做了什么"，最好能把修改前和修改后的关键字段值也记下来，这个在排查问题和责任追溯时会省去很多麻烦。
我这几年测试过不少同类型的开源项目，有些代码看似功能齐全，一跑起来各种问题。这套项目能让我愿意花时间整理和分享，不是因为它的功能有多花哨，而是它的基本功扎实：表结构设计合理，分层清晰，前后端边界明确，常见的坑也都避开了。如果你手头正需要一套人事管理系统的参考实现，或者想通过完整的全栈项目提升实战能力，把这套代码从头到尾过一遍，收获会比零散看教程大得多。
最后再分享一个小技巧：拿到任何一套源码项目，先不要急着跑起来，花半小时把数据库脚本里的表关系梳理一遍，再对照后端 Mapper 里的 SQL 看一遍，项目结构基本就印在脑子里了。带着这个全局认知去跑项目、改代码，效率完全不一样。
