SpringBoot+Vue+MySQL前后端分离HR人力资源管理系统源码解析与实战

如果你正在找一套能直接跑起来的 HR 人力资源管理系统源码，SpringBoot 做后端、Vue 做前端、MySQL 做数据库，那我先给你交个底：这套组合是目前 Java 全栈项目里最稳、最不容易翻车的搭配之一。原因很简单——SpringBoot 把后端工程的复杂度压得很低，Vue 把前端页面组件的开发效率拉得很高，MySQL 又是最普及的关系型数据库，三个东西凑在一起，既适合拿来做课程设计、毕业设计，也适合公司内部快速搭建一套基础的人力资源管理平台。

但"能跑"和"跑得明白"是两回事。很多朋友拿到源码第一件事就是双击启动，结果要么端口冲突、要么数据库连不上、要么前端依赖装了一下午。这篇文章我不仅会带你把项目从 0 到 1 启动起来，还会把系统背后的模块设计、数据库表关系、权限控制逻辑全部拆开讲清楚，并且把我实际踩过的坑、排查思路一并写出来，保证你照着做就能顺畅跑通，也能真明白这套系统为什么这么设计。

1. 这套HR系统到底解决了什么问题，谁最适合拿去用

1.1 人力资源管理的核心痛点

人力资源管理系统（HRM，Human Resource Management）要处理的业务，说白了就是围绕"人"的全生命周期管理。从员工入职前的招聘、面试安排，到入职后的信息登记、部门分配，再到日常的考勤打卡、请假审批、薪资核算，一直到离职交接，每一个环节都需要一套规范化的流程来支撑。传统靠 Excel 和纸质单据管理的方式，在几十人规模时还勉强能撑住，一旦公司人数过百、部门变多、汇报关系复杂起来，数据重复录入、信息不同步、审批追责难这些问题就会集中爆发。

这套基于 SpringBoot + Vue + MySQL 的 HR 系统，核心就是把这些离散流程统一到一个平台上。管理员在后台维护组织结构、设置权限、分配角色；HR 专员录入员工档案、处理考勤和请假；普通员工登录后能查看自己的信息、提交申请。前后端分离的架构让每个角色通过浏览器或者客户端就能完成自己的工作，数据全部落在 MySQL 里，天然解决了信息孤岛问题。

1.2 适合使用这套源码的人群

我接触过不少来问这套项目的人，大概分成三类。

第一类是正在准备毕业设计或课程设计的在校学生。SpringBoot、Vue、MySQL 这三个技术点正好是当前企业级 Java 开发的主流要求，用这套源码去交作业，技术栈覆盖度够、业务完整度够、演示效果也够，尤其是自带权限控制和完整 CRUD，答辩时能讲的东西非常多。

第二类是在中小企业负责信息化建设的技术人员。公司规模不大，采购一套商用 HR 系统动辄几十万，用这套源码做二次开发，把组织架构、员工信息、考勤请假先跑起来，再按公司实际流程去调整，性价比很高。

第三类是正在学习前后端分离开发的初中级工程师。这套项目的前端是 Vue 全家桶，后端是 SpringBoot + MyBatis，整个请求链路、数据流转、权限拦截都清晰可读，拆开来逐段学习，比看零散的教程有效得多。

2. 技术选型背后的工程思维：为什么偏偏是这三个组件

2.1 SpringBoot 后端：把样板代码砍到最少

后端选 SpringBoot，最大的好处是"约定大于配置"这五个字。过去用 Spring MVC 写一个 Web 项目，光配置 XML 文件就要折腾好一阵，数据源、事务管理器、视图解析器、组件扫描，每一块都要手动声明。SpringBoot 用自动配置把这些全部接管了，你只要引入spring-boot-starter-web，内嵌的 Tomcat 就直接帮你把 Web 容器拉起来，一个main方法就能启动整个后端服务。

在实际的 HR 系统中，后端需要提供的是 RESTful API，前端通过 HTTP 请求来获取数据。SpringBoot 的控制器层写起来非常直接，配合 MyBatis Plus 这样的持久层框架，单表的增删改查几乎不用写 SQL，大大缩短了开发周期。举个例子，员工管理模块里最常见的分页查询，MyBatis Plus 的Page对象配合内置方法就能搞定，不需要手写LIMIT语句，更不需要维护一堆繁琐的ResultMap。

提示：这套源码如果用的是 SpringBoot 2.x 版本，依赖包导入的是javax.*；如果升到 3.x 则变成了jakarta.*。跑项目前先看一眼 pom.xml，确认你的 JDK 版本是否匹配——SpringBoot 3.x 必须配 JDK 17 及以上，SpringBoot 2.x 用 JDK 8 就够用了。

2.2 Vue 前端：组件化开发带来的效率提升

前端选择 Vue，和这套系统"表格密集、表单密集、交互频繁"的特点是高度匹配的。HR 系统几乎每个页面都是数据表格配表单弹窗：员工列表要支持搜索、筛选、分页；添加员工要弹出一个包含十几个字段的表单；权限管理要用树形控件展示菜单层级。Vue 的单文件组件（SFC）机制把模板、脚本、样式写在一个.vue文件里，一个业务模块就是一个组件，复用性非常高。

前端工程普遍采用 Vue 全家桶：Vue Router 做路由管理，Vuex（或 Pinia）做全局状态管理，Axios 发 HTTP 请求，Element UI 或 Element Plus 提供现成的表格、表单、弹窗、日期选择器组件。以员工表单为例，Element 的el-form配合校验规则，几十行代码就能实现带有必填校验、手机号格式校验的完整表单，这在 jQuery 时代要写几百行 DOM 操作才能搞定。

这套系统的前后端交互遵循一个标准链路：用户在页面点击操作，Vue 组件触发方法，Axios 把请求发到 SpringBoot 接口，后端处理完返回 JSON，前端拿到响应后更新数据视图。理解这条链路，你就理解了整个系统所有功能模块的运行方式。

2.3 MySQL 数据层：高性价比的持久化选择

MySQL 是这个组合里的"数据大本营"。为什么不用 Oracle、SQL Server？因为这套系统运行在一个中轻量级的业务场景下，MySQL 完全够用，而且部署和运维成本最低。SpringBoot 官方对 MySQL 的连接支持非常成熟，spring.datasource.url一行配置就能连上，配合 MyBatis 或 MyBatis Plus，实体类和表结构之间的映射非常透明。

HR 系统的数据模型有几个显著特点：数据表数量多（通常 20 张以上）、表之间外键关系强（员工表关联部门表、职位表、用户表）、历史数据累积快（考勤记录、操作日志）。MySQL 的 InnoDB 引擎天然支持事务和外键，正好满足这些要求。考勤打卡这种高频写入操作，靠的是合理的索引设计；薪资核算这种多表关联查询，靠的是结构化查询语句和表连接优化。只要表设计得规范，这套系统跑到几千人的数据量都压力不大。

3. 系统模块与数据库设计的完整拆解

3.1 核心业务模块清单

一套完整可运行的人力资源管理系统，代码层面会拆成若干功能模块。下面这份模块清单是我基于同类系统源码总结出的典型结构，你可以对照自己手里的项目逐一验证：

系统管理模块是整套系统的地基。它做的事简单说就是"谁能登录、登录后能看什么、能操作什么"。常见的权限模型是 RBAC（Role-Based Access Control，基于角色的访问控制），用户关联角色、角色关联菜单，一个用户登录后根据角色动态生成可见的菜单和可操作的按钮权限。这套模型在 HR 系统里特别实用——HR 经理能看所有员工的薪资，而普通主管只能看本部门员工的基础信息，这就是权限粒度上的差异。

员工管理模块是 HR 系统的"门面"。它承担了员工全生命周期信息的管理，包括基础信息（姓名、性别、身份证号、手机号）、任职信息（部门、职位、入职时间、转正时间）、学历信息（毕业院校、专业、学历层次）、合同信息（合同开始时间、结束时间、合同类型）。这些字段在后端对应一个employee主表加若干关联子表。设计时要注意身份证号、手机号这类敏感字段的存储规范，尽量做到加密存储或脱敏展示。

3.2 表结构设计中的几个关键决策

数据库表设计的好坏，直接决定后面写业务代码的时候是省力还是痛苦。我拆解这套源码的建表 SQL 时，会重点关注下面几个设计点。

第一，主键策略。绝大多数表会采用bigint类型的自增主键，也有部分系统使用雪花算法生成的分布式 ID。在单库单表的部署场景下，自增主键简单高效，索引性能也好；如果你打算以后做读写分离或分库分表，就得在一开始设计时就考虑分布式 ID 方案。

第二，逻辑删除 vs 物理删除。员工离职后，他的数据能不能直接从employee表里删掉？几乎所有正规系统都会回答"不能"——离职记录涉及薪资历史、考勤历史、社保缴费记录，这些数据都需要长期留存供审计查询。因此员工表里通常会有一个逻辑删除标志字段，取值 0 表示在职或有效，取 1 表示逻辑删除。每次查询时都要带上WHERE deleted = 0的条件（MyBatis Plus 也有逻辑删除插件可以自动拼上这个条件）。

第三，时间字段的规范。create_time（创建时间）、update_time（更新时间）几乎每张表都要有，用datetime类型，后端实体类用LocalDateTime接收。MySQL 8.0 的话可以直接用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP来自动维护时间，省去业务代码里的手动 set。

以员工表和部门表的关系为例，employee.dept_id外键指向dept.id，查询员工列表时需要通过关联查出部门名称。这类多表联查在 MyBatis Plus 里有两种做法：一种是写自定义 SQL 用JOIN；另一种是保留冗余字段，在员工表里直接存一个dept_name，插入或更新时由后端代码回填。小项目里用冗余字段能省不少联查，但要注意数据一致性。

4. 从零到一跑通项目的实操指南

4.1 环境准备：先把地基打牢

跑这套系统之前，得先把环境准备到位。下表是我建议的版本组合，如果你手里已经有其他版本，只要大版本兼容也行，但最好以项目的pom.xml和package.json里声明的版本为准：

安装 MySQL 后，你需要手动创建一个数据库，比如命名为hr_system，字符集用utf8mb4——这个字符集比utf8更全，能存下表情符号，也能避免一些生僻字写入报错的问题。然后把你从源码里找到的.sql建表脚本（通常在sql/目录或db/目录下）导入进去：

mysql -uroot -p CREATE DATABASE hr_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hr_system; SOURCE /你的路径/hr_system.sql;

后缀的三条语句分别完成创建库、选中库、执行脚本文件的操作。导入后可以用SHOW TABLES;验证表是否全部建成功。

4.2 后端启动三步走

第一步，打开application.yml，把数据源配置改成你自己本机的数据库地址和密码。这个文件里你需要重点关注三块内容：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/hr_system?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

务必检查serverTimezone参数，常见报错 "The server time zone value" 就是没设对时区造成的。useSSL=false是避免本地连接时出现 SSL 认证警告。数据库密码千万不要用 root 的默认空密码去连，MySQL 8.0 默认要求认证插件是caching_sha2_password，如果连不上，可以建一个专门账号或用mysql_native_password方式做兼容。

第二步，用 IDEA 导入 Maven 项目，等右下角的依赖下载进度条走完。国内网络环境下 Maven 下载依赖经常卡住，建议在settings.xml里配置阿里云镜像。等依赖全部导入后点启动，看到Started Application in X.XXX seconds就说明后端已经起来了。

第三步，验证后端接口是否正常。浏览器访问http://localhost:8080/，如果项目配置了 Swagger，访问/swagger-ui.html或/doc.html能直接看到接口文档；如果配了统一登录校验，未登录状态访问接口可能会返回 401 或跳转到登录提示，这都说明服务在正常运行。

4.3 前端启动与登录验证

后端跑通后，进入前端目录（一般是frontend/或web/），打开终端执行：

npm install

这一步是安装 Vue 项目依赖，耗时取决于网络状况。如果报 node-sass 安装失败或gyp ERR，多半是 Node 版本和依赖不兼容——这个坑我后面细说。依赖安装成功后启动开发服务器：

npm run serve

启动日志里会给出一个访问地址，默认是http://localhost:8082/或http://localhost:3000/，可能和后端端口不同。Vue 开发服务器有热更新机制，代码改动保存后页面会自动刷新。

前端启动后的第一件事是验证"前端能不能调到后端"。你需要在开发环境配置里找一下有没有跨域代理设置，常见位置是根目录的vue.config.js：

module.exports = { devServer: { port: 8082, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };

配置代理后，前端请求/api/xxx会由 devServer 转发到后端的8080端口，从而绕开浏览器同源策略的跨域限制。登录页面输入初始管理员账号（源码的 README 里会写明，通常是admin/123456，这个要看建表 SQL 里sys_user表的初始数据），能成功跳转到首页，就说明整套项目的运行链路已经打通了。

5. 我实测中踩过的高频坑位，每条都写清楚了排查过程

5.1 数据库连接失败：从报错去反推问题根源

"微信 app, 数据库连接失败"是这一类项目最常见的问题。我遇到过两个典型的报错场景。

第一个是Access denied for user 'root'@'localhost'。这种基本是密码配置错误，或者 MySQL 的认证插件不兼容。SpringBoot 2.x 用的 MySQL Connector/J 版本较旧时，连接 MySQL 8.0 的默认账号会遇到认证方式不支持的问题。排查时我建议分三步：先在命令行mysql -uroot -p确认密码能正常登录；再用一个简单的 JDBC 测试类或数据库客户端（如 Navicat、DBeaver）测试远程连接；最后检查application.yml里的url有没有拼错参数。不要一上来就怀疑代码。

第二个是Unknown database 'hr_system'。出现这个，多半是建库脚本没有执行成功，或者库名拼写不一致。进 MySQL 里执行SHOW DATABASES;看一眼真实存在的库名，再和配置里的url对一下，基本秒解决。

5.2 端口占用：不是代码问题，是环境冲突

后端启动时如果报Port 8080 was already in use，说明 8080 端口已经被其他进程占了。这种情况在本地开发环境特别常见，可能是别的开发服务占用，也可能是你之前启动过一个没关掉的实例。

Windows 下用这条命令找到占用进程的 PID，再到任务管理器里把它结束掉：

netstat -ano | findstr :8080

Linux / macOS 下用：

lsof -i :8080

想省事的话，也可以直接把application.yml里的启动端口改为 8081 或 9090，改完之后后端的接口地址就变了，前端的代理路径也要同步修改。这里我建议优先杀进程而不是改端口——如果你改动了启动端口，前端vue.config.js里代理的target也得跟着改，多了一个容易忽视的连带环节。

5.3 前端启动报错 node-sass / gyp ERR：Node 版本和依赖不匹配

前端npm install报gyp ERR! stack Error: not found: python2，或者 node-sass 安装失败，这可以说是 Vue 2 项目最经典的"年龄问题"。node-sass 对 Node 的版本兼容性很差，Node 17 以上版本装旧版的 node-sass 几乎必挂。

这类问题我总结出三条路可以走。

第一条路，用项目package.json里锁定的版本去对齐 Node。比如项目依赖 node-sass 4.14 版本，配 Node 14 是最稳的。你可以用 nvm（Node Version Manager）切换 Node 版本，再重新npm install。

第二条路，把 node-sass 换成 dart-sass（即 sass 包）。这是官方推荐的替代方案，兼容性更好、安装不需要编译原生模块。改法是卸载 node-sass、安装 sass，然后项目里webpack配置或全局的vue.config.js里把 loader 的implementation指向新的 sass 依赖。

第三条路，是移除对 node-sass 的依赖，直接看项目里到底哪些样式文件用了.scss，如果只是零散使用，可以改为普通 CSS。这个方式动静最大，一般不建议第一优先级尝试。

5.4 登录后接口 404 或数据加载不出来：代理路径与后端路由不匹配

前端页面能打开，但登录后列表数据一直转圈或者提示请求失败，这是前后端联调最常见的另一个坑。排查思路要从浏览器开发者工具的 Network 面板开始：点击 F12，看请求发出了没有、请求地址是什么、返回状态码是多少。

如果请求状态是 404，多半是代理路径转发的地址不对。比如前端请求的/api/employee/list，后端 Controller 的映射是/employee/list，代理配置里'/api'转发到后端时没有做路径重写，结果后端收到的就是/api/employee/list，自然 404。

解决方式有两种：后端在类上补@RequestMapping("/api")；或者前端代理配置里做路径重写，把/api前缀去掉再转发。以http-proxy-middleware为例：

proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } }

如果请求状态是 401 或 403，那就是权限认证拦截器拦住了。检查前端请求头里有没有自动加上Authorization: Bearer token——很多项目封装的 Axios 工具会在请求拦截器里统一加这个头，如果你直接拿浏览器地址栏去访问接口，就绕过了前端拦截器，自然会被后端拦下来。

6. 二次开发时我一定会优先动刀的四个扩展方向

6.1 权限模型从角色控制升级到数据范围控制

基础版 RBAC 控制的只是菜单和按钮的可见性，但 HR 业务场景里，"同一角色不同数据范围"的需求非常常见。比如两个部门主管角色相同，部门 A 的主管不应该查到部门 B 的员工。这一般不能靠前端隐藏按钮来实现，必须在后端查询时做数据权限过滤。实现思路是在部门表上维护层级parent_id，查询员工列表时根据当前登录用户的dept_id找到子部门集合，再用IN条件拼进 SQL。在原项目上改这个功能，核心改的是后端的查询拦截逻辑或 Mapper XML，前端几乎不用动。

6.2 导入导出功能要尽早补上

HR 系统和 Excel 打交道非常频繁。员工信息批量导入、考勤记录导出、薪资表导出，这些场景如果每次都要人工一条条录入，HR 的实际使用意愿会大打折扣。当前端用 Element UI 的el-upload上传文件时，后端可以基于 Easy Excel 这类工具来解析和生成 Excel，性能好、内存占用低，而且支持复杂表头。这块功能虽然简单，但对系统实用性的提升是质的飞跃。

6.3 审批流的可配置化改造

这套源码里的请假、加班审批流程往往是写死的——比如一级主管审批后自动流转到 HR 审核。但真实企业里审批流和责任人的规则千差万别。想彻底解决，可以引入 Flowable 或 Activiti 这类工作流引擎，把流程定义做成 BPMN 文件，实现可视化配置。不过工作流引擎的引入会显著增加系统复杂度，如果团队时间紧，建议先用一个简单的审批配置表来实现"按部门层级自动找审批人"，性价比更高。

6.4 文件存储与消息通知的落地

员工头像、合同附件上传，这类文件处理功能如果还是把文件直接放在后端本机磁盘，那部署到服务器时就容易出问题——多实例部署场景下文件不一致，备份也不方便。建议尽早统一用对象存储服务对接，代码层面抽象出一个FileStorageService接口，本地存储实现和云存储实现可以自由切换。消息通知模块同理，可以接入邮件或企业微信机器人，审批流有变更时自动提醒相关人，避免 HR 一直盯着后台刷新状态。

最后说说我对这套系统源码的一点个人操作体会

这套 SpringBoot + Vue + MySQL 的 HR 系统，我从拿到手到完整跑通，最耗时的不是业务代码，而是环境对齐的过程。JDK 版本、Node 版本、MySQL 版本，任何一个版本错位都会冒出来一些莫名其妙的怪问题。所以我想留给你的最重要一条经验是：拿到源码之后，先别急着看代码，第一件事是打开pom.xml和package.json把版本依赖捋清楚，再对照本机环境做版本匹配。这一步做好了，后面启动过程会顺很多。另一个我觉得特别值得做的事情，是去读一遍建表 SQL——整个系统的业务边界和功能划分其实全藏在那几十张表里面，表关系看懂之后，再去读 Controller 和 Service 的代码，你会发现自己对这套系统的理解一下子立体了。如果后续你想把项目真正用到生产环境，把application.yml里的数组库密码等敏感配置改成环境变量注入，再把前端的构建产物用 Nginx 托管，并和 SpringBoot 接口做反向代理，这套系统的部署形态就接近一个真正可靠的产品了。