简介：面向Java毕业设计与课程设计学生，这份基于SpringBoot+Vue开发的企业人力资源管理系统，覆盖员工档案、考勤、薪酬、权限等常见业务模块，前后端源码完整，可直接作为毕业设计、期末大作业或课程设计的基础项目。压缩包共909个文件，核心包括130个Java源文件、96个Vue前端页面、322个SVG图标，以及129个class文件、SQL数据库脚本、Maven配置和部署批处理脚本，整体31.51MB，便于下载与本地部署；其中SQL脚本可快速完成建库建表，BAT脚本简化启动过程，能节省环境准备时间。系统代码注释清晰，项目经过严格调试确保可运行，前端Vue与后端SpringBoot分离，开发环境基于IntelliJ IDEA，数据库使用MySQL 5.7，部署建议配合Tomcat 7/8。已有1195人学习下载，压缩包内附有数据库脚本、软件工具与部署脚本，能帮助缺少完整项目经验的学生减少环境配置障碍，快速进入开发与答辩准备。
1. 为什么选这套SpringBoot+Vue人事系统：毕业设计答辩最稳的组合
作为SpringBoot毕业设计的热门方向，企业人力资源管理系统几乎是Java后端最容易出活也最容易翻车的选题。说它容易，是因为功能边界清晰，无非是员工信息、部门、考勤、薪资、角色权限这几张表来回转；说它容易翻车，是因为大多数同学拿到源码后直接 run 起来就以为完事了，结果答辩时被老师一句「你这个登录是怎么做鉴权的」问得当场卡壳。这套基于SpringBoot+Vue的现代企业人力资源管理系统，把前后端分离、RBAC权限模型、考勤统计这些毕业设计高频考点都覆盖到了，源码里自带数据库脚本和完整的Vue前端工程，适合拿来二次开发，也适合作为模板理解一个真实业务系统从数据库到接口再到页面的完整链路。
2. 系统拆解与技术选型：四个角色、六大模块、REST接口怎么定
拿到一套源码，第一步不是急着启动，而是先把项目结构读透。这套系统的后端是标准的SpringBoot工程，前端是Vue 2 + Element UI，数据库用MySQL。整体架构不复杂，但模块划分是典型的企业级写法，和网上那些「登录+增删改查」的玩具项目有本质区别。
2.1 功能模块与角色权限边界
系统内置了四个角色：超级管理员、HR专员、部门经理、普通员工。你别小看这个设计，它是整个RBAC权限模型的核心。超级管理员能看全部菜单，HR专员操作员工和考勤模块，部门经理只能看本部门数据，普通员工只能查自己的信息和工资条。这套权限边界在数据库里是通过sys_user_role和sys_role_menu两张关联表实现的，前端路由和后端接口同时做了拦截。
六大模块分别是系统管理（用户、角色、菜单）、员工管理、部门管理、考勤管理、薪资管理、个人中心。每个模块对应一组REST接口，接口路径统一以/api开头，例如/api/employee/page是员工分页查询，/api/attend/statistics是考勤统计。我在拆这套源码时比较欣赏的一点是，接口的响应格式统一封装成了{ code, msg, data }结构，前端axios拦截器直接按这个结构做统一处理，不用每个页面单独写错误提示。
2.2 技术选型理由：为什么是MyBatis-Plus而不是JPA
后端持久层用的是MyBatis-Plus，不是Spring Data JPA。这是国内企业项目的常见选择，也是你们答辩时容易被追问的点。MyBatis-Plus的优势在于单表CRUD不用写SQL，BaseMapper接口已经内置了selectById、selectPage这些方法，但复杂查询又可以用@Select注解或XML写原生SQL。这套系统的考勤统计和部门树查询就用到了自定义SQL，算是把MyBatis-Plus的灵活性和效率都体现出来了。
前端Vue部分，路由用的vue-router，状态管理用了Vuex，UI组件库是Element UI。需要提醒一点，如果你的电脑装的是Vue 3，这套前端代码大概率跑不起来，因为它是Vue 2的写法（this.$router、Vue.use这种），用Vue CLI 4.x来跑最稳。Nginx代理配置里把/api转发到后端localhost:8080，这个细节后面部署章节会细说。
3. 数据库设计与建表脚本：六张核心表把权限和流程一次讲清
人力资源管理系统这类毕业设计的数据库设计，说穿了就是「用户-角色-权限」三件套加业务表。但表与表之间的关联关系处理得好不好，直接决定你在答辩时能不能说清楚。
3.1 六张核心表的结构与关联
我对照源码里的hrms.sql脚本梳理了核心表结构，六张表搞定核心业务：sys_user（用户表）、sys_role（角色表）、sys_menu（菜单表）、sys_user_role（用户角色关联）、sys_role_menu（角色菜单关联）、employee（员工信息表）。考勤和薪资表也有，但属于业务明细表，和权限模型解耦。
sys_user表里除了常规的username、password，还有个status字段控制账号启用禁用。密码字段存的是BCrypt加密后的哈希值，不是明文，这一点答辩时一定要主动提，属于安全设计的加分项。sys_menu表的设计有点意思，它用parent_id做父子层级，component字段保存Vue组件的路径，菜单和路由是动态绑定的——数据库里配了菜单，前端登录后自动生成对应路由，这个设计能直接回答「菜单是怎么来的」这个问题。
3.2 建表SQL与关键字段说明
-- 用户表：核心账号信息 CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `real_name` varchar(50) DEFAULT NULL COMMENT '真实姓名', `email` varchar(100) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `status` tinyint(4) DEFAULT '1' COMMENT '1启用 0禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 菜单表：parent_id实现树形结构，component绑定Vue组件路径 CREATE TABLE `sys_menu` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `parent_id` bigint(20) DEFAULT '0' COMMENT '父菜单ID，顶级为0', `menu_name` varchar(50) NOT NULL, `path` varchar(200) DEFAULT NULL COMMENT '路由路径', `component` varchar(200) DEFAULT NULL COMMENT 'Vue组件路径', `icon` varchar(50) DEFAULT NULL, `sort_order` int(11) DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 员工表：与sys_user通过user_id做一对一关联 CREATE TABLE `employee` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) DEFAULT NULL COMMENT '关联sys_user.id', `emp_no` varchar(20) NOT NULL COMMENT '工号', `dept_id` bigint(20) DEFAULT NULL COMMENT '所属部门', `position` varchar(50) DEFAULT NULL COMMENT '岗位', `entry_date` date DEFAULT NULL, `salary` decimal(10,2) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这段SQL里有几个字段是答辩时的关键论据。sys_user的password字段明确标注BCrypt加密，可以直接反驳「密码明文存储」这类低级问题。sys_menu表的component字段，决定了前端路由是静态配置还是动态生成——这套系统是动态生成，所以新增菜单不需要改前端代码。employee表通过user_id和sys_user做一对一关联，这样账号体系和员工档案分离，离职时只禁用账号不动档案，逻辑上更干净。
3.3 初始化数据：admin账号和角色种子数据
源码的SQL脚本末尾有一段初始化数据，我建议你先别急着跑完整脚本，而是把这段种子数据单拎出来看。默认账号是admin/admin123，角色表预置了四个角色，超级管理员关联了全部菜单ID。如果你想快速验证权限效果，可以手动往sys_user_role里插一条数据，把某个测试账号绑到普通员工角色，然后重新登录看菜单变化——这是演示RBAC最直观的方式，答辩现场操作非常加分。
4. 后端核心实现：JWT登录、组织架构树、考勤统计三块硬骨头
这套系统的后端代码里，有三块实现值得重点拆解，也是你二次开发时最可能改到的地方：登录鉴权、组织架构树的递归组装、考勤统计的SQL聚合。
4.1 JWT登录与拦截器配置
登录接口的逻辑很标准：接收用户名密码，用BCryptPasswordEncoder.matches校验密码，通过后生成JWT令牌返回前端。令牌里只放userId和username，过期时间默认2小时。后端有一个JwtInterceptor实现了HandlerInterceptor接口，在WebMvcConfig里注册并指定拦截路径/api/**，同时用excludePathPatterns放行了登录接口。
// JwtInterceptor核心逻辑：从请求头取token并校验 public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 放行预检请求，否则前端跨域会出问题 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { // 解析token，把用户ID塞到request属性里供后续接口使用 Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; }这段代码的关键不是JWT生成本身，而是OPTIONS请求的处理。前后端分离项目跨域时，浏览器会先发一个OPTIONS预检请求，如果你不把它放行，前端所有请求都会报跨域错误但后端日志里什么都看不到。我见过不少同学在这里翻车，排查了半天最后发现是拦截器把预检请求拦了。接口里拿当前登录用户ID的方式是request.getAttribute("userId")，这是Java Servlet标准写法，配合HandlerMethod参数解析器可以做到方法参数直接注入，但这套系统用的还是传统方式，理解成本更低。
4.2 组织架构树的递归组装
部门管理模块有一个「懒加载树」接口，前端展开节点时才加载子部门。后端实现用的是递归查询，而不是一次性把全量数据查出来。
// 部门树节点：返回给前端的数据结构 @Data public class DeptTreeNode { private Long id; private String deptName; private Long parentId; private List<DeptTreeNode> children = new ArrayList<>(); } // 递归组装部门树 public List<DeptTreeNode> buildDeptTree(Long parentId) { // 查询当前父ID下的直接子部门 List<Dept> deptList = deptMapper.selectList( new LambdaQueryWrapper<Dept>() .eq(Dept::getParentId, parentId) .orderByAsc(Dept::getSortOrder) ); List<DeptTreeNode> tree = new ArrayList<>(); for (Dept dept : deptList) { DeptTreeNode node = new DeptTreeNode(); node.setId(dept.getId()); node.setDeptName(dept.getDeptName()); node.setParentId(dept.getParentId()); // 递归查询子部门，这里控制了层级 node.setChildren(buildDeptTree(dept.getId())); tree.add(node); } return tree; }这个递归的关键在于：每层查询只查parent_id等于当前节点ID的数据，天然避免了死循环，前提是数据库里部门数据的父子关系不能出现环。如果你在后台测试时发现某个部门展开后前端卡死，先检查是不是有部门把父级设成了自己的子部门——这种脏数据在真实企业里很常见。另外LambdaQueryWrapper是MyBatis-Plus的链式条件构造器，eq是等于条件，orderByAsc是排序，这套语法是MyBatis-Plus的核心用法，答辩时被问「你条件查询怎么写的」就引这段。
4.3 考勤统计的SQL聚合
考勤模块比较实用的一点是月度统计报表，后端用一条SQL同时算出了出勤天数、迟到次数、早退次数。这里没有用Java循环去逐条统计，而是直接依赖SQL的GROUP BY和SUM(CASE WHEN ...)。
-- 月度考勤统计：根据打卡记录聚合 SELECT DATE_FORMAT(clock_time, '%Y-%m') AS month, employee_id, COUNT(DISTINCT DATE(clock_time)) AS work_days, SUM(CASE WHEN status = 'late' THEN 1 ELSE 0 END) AS late_count, SUM(CASE WHEN status = 'early_leave' THEN 1 ELSE 0 END) AS early_count FROM attend_record WHERE clock_time BETWEEN #{startDate} AND #{endDate} GROUP BY employee_id, DATE_FORMAT(clock_time, '%Y-%m')这种写法比Java内存统计快了不止一个量级，而且可读性强。需要注意COUNT(DISTINCT DATE(clock_time))这个写法，因为员工一天可能打多次卡，直接用COUNT(*)会把重复打卡算成多天出勤。这个细节是我在实际开发中踩过坑的，当时统计结果比实际出勤天数多了一倍，查了半天才发现是SQL少写了DISTINCT。移植到你的项目时，记得把startDate和endDate参数格式统一成yyyy-MM-dd，否则MySQL的隐式转换会让你莫名丢数据。
5. 避坑与常见问题：启动失败、白屏、乱码六条实战记录
源码能跑起来不代表没问题，我按「现象 → 原因 → 解决」的格式把最常见的问题整理出来，这些坑几乎每个跑这套系统的人都会踩一遍。
5.1 启动与环境类坑
现象一：后端启动直接报Access denied for user 'root'@'localhost'。原因是数据库账号密码和application.yml配置不一致，或者MySQL没启动。解决方法是先确认MySQL服务已启动，然后核对配置文件里spring.datasource.username和password字段，注意检查是不是因为之前在别的项目里改过root密码。
现象二：前端npm run serve报Module build failed，各种依赖版本冲突。原因大概率是Node版本太高，Vue 2 + node-sass的组合在Node 17以上会编译失败。这几乎是Vue 2项目的通病，node-sass和Node版本有强绑定。解决方法是package.json里node-sass改成sass并使用dart-sass，或者直接换成Node 14。我一般建议装一个nvm管理Node版本，切到14再跑。
现象三：后端启动成功但端口被占用。原因是8080端口被其他进程占用了，常见的是本地跑着其他SpringBoot项目。解决方式有两种，要么关掉占用进程，要么改application.yml的server.port为8081，同时记得把前端vue.config.js里的代理转发目标也改成8081，两个地方不一致前端会报Proxy error。
5.2 前后端联调类坑
现象四：前端登录时提示跨域，浏览器控制台报CORS error。原因比较隐蔽——后端虽然写了跨域配置，但SpringBoot的CorsFilter和拦截器有执行顺序问题。解决方法是检查WebMvcConfig里是否实现了addCorsMappings方法，同时确认拦截器放行了OPTIONS请求。如果两者都做了还报错，那大概率是Nginx层没配代理，本地开发直接用vue.config.js的devServer.proxy就能解决。
现象五：登录成功后跳转首页白屏，控制台报Cannot read properties of undefined (reading 'xxx')。原因是动态菜单渲染时，Vuex里存的menuList还没拿到数据，页面组件就渲染了。解决方法是加个v-if判断，或者用nextTick在路由跳转后再渲染，更简单的方式是登录后先跳转到一个空路由中间页，让菜单异步加载完成后再跳首页。
现象六：查询列表中文乱码，数据库里也乱。原因是建库时字符集不是utf8mb4。解决方法是建库语句改成CREATE DATABASE hrms DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;，同时修改application.yml连接串加上characterEncoding=utf8。这里有个血泪经验：只改连接串不够，表里已经写入的乱码数据修不回来，必须连库重建，所以密码别乱改，库别乱建，动之前先备份。
6. 进阶玩法：答辩演示脚本与Redis会话改造
源码跑通只是起点，真正让你的毕业设计高出别人一档的，是下面这两个进阶操作。
第一个是答辩演示脚本。我会建议你准备一条「从登录到查工资条」的完整演示动线，时间控制在5分钟内。开场先展示数据库表结构，讲清楚RBAC四张表的关联关系——这是你最熟悉的部分，先讲能建立自信。然后演示超级管理员登录，打开系统管理菜单，现场创建一个新用户并绑定「普通员工」角色。关键操作在这里：退出登录，用刚创建的新账号登录，菜单列表明显变少——这个视觉对比效果非常直接，评委会立刻明白你的权限控制是前后端同时生效的。
第二个进阶是改造Redis会话。当前系统的JWT是无状态的，token校验依赖JWT签名，如果想让token能够在退出时立即失效，就需要引入Redis。改造点只有三个：登录成功后把token写入Redis并设置过期时间，JwtInterceptor校验时先检查Redis里是否存在该token，退出登录时删除Redis里的key。这三步代码量不大，但能在答辩时讲清楚「JWT无状态认证的局限性和Redis弥补方案」，这是很多项目都没考虑过的深度。
从实际就业角度说，这个改造方向也贴近企业真实场景。我在现公司做的系统就是Redis存储用户会话，用userId作为key，token作为value，每次请求从Redis取token比对，比单纯JWT多一次IO但可控性更强。你如果时间充裕，建议把这块改了。从那以后我每次跑这套系统，都会强制走一遍检查三个文件：application.yml的数据库配置、vue.config.js的代理地址、sys_menu表的初始化数据，这三处没问题基本一把过。希望帮到你。
本文还有配套的精品资源，点击获取
