SpringBoot+Vue2人事系统全栈源码，含数据库脚本与模块化分层结构

本文还有配套的精品资源，点击获取

简介：这套人事管理系统源码采用前后端分离架构，后端基于SpringBoot 2.x（Java语言），整合MyBatis做数据持久化，Spring Security + JWT实现登录认证与权限控制；前端使用Vue 2.x（非Vue3），包含完整路由配置、角色权限拦截、组件化页面及响应式布局；配套vhr.sql数据库脚本，适配MySQL一键导入；项目按标准分层组织：kfk-model（实体类）、kfk-mapper（DAO接口与XML映射）、kfk-service（业务逻辑）、kfk-web（Controller层）、kfk-server（服务聚合层），结构清晰便于理解与扩展；提供vue.config.js、babel.config.js、package.、pom.xml等全套构建配置文件，以及README.md使用说明和MIT授权的LICENSE文件；适合Java/Vue初学者学习全栈开发流程，也支持企业内部快速二次开发或教学演示。

1. 这套人事系统到底解决了什么问题？为什么值得花时间啃透它？

我带过十几期Java全栈训练营，每次讲到权限系统时，学员最常问的一句话是：“老师，能不能给我一个真实可用的、不是Demo级别的权限管理例子？”——不是那种登录后跳转首页就完事的“Hello World”，而是真正在企业里跑得起来的：能区分管理员、HR专员、普通员工角色；能控制菜单显示、按钮可见性、接口访问权限；能记住用户上次登录位置；能防止越权访问员工薪资字段；还能在数据库增删改查层面做细粒度拦截。这套SpringBoot+Vue2人事系统，就是我反复打磨后选出来当“标准答案”的那个项目。

它不是玩具，也不是教学简化版。你看到的kfk-server模块，其实是把微服务思想提前落地到了单体架构里——它不直接处理HTTP请求，也不碰数据库，只负责协调kfk-web和kfk-service之间的调用边界，让业务逻辑层真正“干净”；你打开vhr.sql脚本，会发现sys_user_role、sys_role_menu、sys_menu_permission三张关联表设计得非常克制，没有过度抽象成“资源-操作-策略”这种学术派模型，而是用“菜单+按钮+数据范围”三层控制，既覆盖了95%的企业场景，又避免了初学者被ACL、RBAC、ABAC概念绕晕。前端Vue2部分更实在：路由守卫不是简单判断token是否存在，而是解析JWT里的roles数组，动态生成侧边栏菜单；按钮级权限不是靠v-if硬写$store.state.user.roles.includes('admin')，而是封装成<auth-button code="emp:delete">删除</auth-button>这样的自定义指令，所有权限校验逻辑收口在permission.js里——这意味着你改一个地方，全站按钮权限就同步更新。

关键词里提到的“Java权限管理”和“MySQL人事数据库”，恰恰是这套源码最扎实的落点。它没用Shiro这种老框架，也没上Spring Security OAuth2这种重型方案，而是用Spring Security + JWT组合拳打出了极高的性价比：登录成功后返回带user_id、username、roles、permissions四个关键字段的Token；每次请求携带Token，后端通过JwtAuthenticationFilter解析并注入SecurityContext；权限校验时，@PreAuthorize("hasAuthority('emp:update')")直接生效，背后是JwtUserDetailsService从数据库加载用户权限树并缓存到ConcurrentHashMap里。整个链路清晰、可调试、可打断点，不像某些开源项目把权限逻辑藏在N个AOP切面里，让你连断点都打不到。

对初学者来说，它像一本立体化的《SpringBoot实战》教科书：pom.xml里每个依赖都有明确用途（比如spring-boot-starter-validation专管参数校验，mybatis-spring-boot-starter负责DAO层接入），不会堆砌spring-boot-starter-webflux这种用不上的东西；kfk-model包下每个实体类都标注了@Data、@TableName、@TableField，连@TableLogic软删除字段都配好了；kfk-mapper里的XML文件，SQL语句全用<if>动态拼接，而不是手写一堆findByDeptIdAndStatusAndNameLike这种爆炸式方法名。Vue2部分同样友好：main.js里Vue.use()加载的插件都是刚需（vue-router、vuex、axios），store/modules/user.js里login action封装了完整的登录流程——发请求、存token、初始化用户信息、跳转首页，一气呵成。这不是教你“怎么写代码”，而是告诉你“一个靠谱的系统应该长什么样”。

2. 项目整体架构设计与分层逻辑拆解

2.1 为什么采用五层模块化结构？而不是常见的三层或四层？

很多教程讲分层，动不动就是Controller-Service-Mapper三层，或者加个DTO变成四层。但这套系统坚持用kfk-model、kfk-mapper、kfk-service、kfk-web、kfk-server五层，表面看是“过度设计”，实则每一层都有不可替代的职责边界。我拿员工信息查询这个典型场景来拆解：

当你在前端点击“查看员工详情”，请求路径是GET /api/employee/123，这个请求首先进入kfk-web模块的EmployeeController。这里只做三件事：校验URL参数合法性（@PathVariable Long id）、调用kfk-server暴露的服务接口、将结果包装成统一响应格式（Result.success()）。它绝不处理任何业务逻辑，比如“是否允许查看该员工薪资”这种判断，也不做数据库查询——这是为了保证Web层纯粹作为HTTP协议适配器，方便未来替换成Spring WebFlux或直接对接网关。

真正的业务逻辑在kfk-server模块里。它提供IEmployeeService接口，实现类EmployeeServiceImpl里才开始做权限校验：先查当前用户角色，再根据角色查出可访问的数据范围（比如HR专员只能看本部门员工），最后调用kfk-service的EmployeeService获取原始数据。注意，这里的kfk-service和kfk-server是两个独立模块——kfk-service专注领域逻辑（如计算工龄、生成工号规则），而kfk-server专注跨域、事务、权限等横切关注点。这种分离让kfk-service可以被其他模块复用（比如考勤模块也需要查员工基本信息），而kfk-server则可以统一管理所有业务模块的权限入口。

数据访问层kfk-mapper彻底屏蔽了MyBatis细节。它的EmployeeMapper接口只定义方法签名，XML文件里写SQL，但所有SQL都遵循一个原则：绝不出现硬编码的WHERE条件。比如查询员工列表，XML里是<where><if test="deptId != null">AND dept_id = #{deptId}</if><if test="status != null">AND status = #{status}</if></where>，这样kfk-service传入的查询条件对象就能自动映射。更重要的是，kfk-mapper模块的pom.xml里只依赖mybatis-spring-boot-starter和mysql-connector-java，不引入任何Spring Security或Web相关jar包——这是模块隔离的铁律。

kfk-model层看似简单，却是整个系统的基石。它包含Employee、Role、Menu等实体类，每个类都用Lombok的@Data减少样板代码，但关键在于字段注解：@TableField("salary")明确指定数据库列名，避免驼峰命名自动转换出错；@TableLogic标记is_deleted字段为逻辑删除；@JsonIgnore控制JSON序列化时忽略敏感字段（如密码）。这些注解不是装饰，而是把ORM框架的隐式行为显性化，让你一眼看清“这个字段在数据库里叫什么”、“这个字段是否参与JSON输出”。

最后，kfk-server模块的pom.xml里有个容易被忽略的配置：<scope>provided</scope>。它把kfk-web、kfk-service、kfk-mapper都声明为provided依赖，意味着编译时需要，但打包时不打入最终jar包。这样做的好处是：当你要把kfk-server部署到不同环境（比如测试环境用H2内存库，生产环境用MySQL），只需替换kfk-mapper模块的数据库驱动jar包，其他模块完全不用动——这就是模块化带来的部署灵活性。

2.2 前后端分离不是口号，而是体现在每一个技术决策里

很多人以为前后端分离就是“前端用Vue，后端用SpringBoot”，但真正的分离体现在通信契约、错误处理、开发协作三个维度。这套源码在这三点上做得非常到位。

首先是通信契约。所有API都遵循RESTful风格，但更关键的是统一响应体结构。后端Result<T>类强制规定：code字段表示业务状态（200成功，500系统异常，401未登录，403无权限），msg字段是人类可读的提示（如“您没有删除员工的权限”），data字段承载业务数据。前端utils/request.js里service.interceptors.response.use统一拦截响应，遇到code !== 200就弹出Message.error(res.data.msg)，而不是让每个组件自己判断res.status === 403。这种契约让前端开发者不需要关心后端用了什么框架，只要拿到Result对象就能处理；也让后端开发者不必为每个接口写重复的try-catch包装逻辑。

其次是错误处理的分层。后端抛出的异常被GlobalExceptionHandler全局捕获，但捕获后不是简单返回500，而是按类型精细化处理：CustomException（业务异常）返回Result.fail(e.getMessage())，MethodArgumentNotValidException（参数校验失败）提取BindingResult里的第一个错误信息返回，AccessDeniedException（权限拒绝）返回Result.fail("权限不足")。前端对应地，在router/index.js里配置了全局路由守卫：router.beforeEach(async (to, from, next) => { if (to.meta.requiresAuth && !getToken()) { next('/login'); return; } ... })，这里requiresAuth是路由元信息，由后端接口文档约定，前端无需猜测哪些页面需要登录。

最后是开发协作的便利性。vue.config.js里配置了devServer.proxy，把/api/**请求代理到http://localhost:8080，这样前端启动npm run serve时，所有API请求自动转发到后端SpringBoot服务，不需要修改任何代码就能联调。更妙的是package.json里的"scripts"："build:prod": "vue-cli-service build --mode production"和"build:test": "vue-cli-service build --mode test"，配合.env.production和.env.test文件，让前端能一键构建不同环境的静态资源。后端application-prod.yml里server.port=8080、spring.profiles.active=prod，和前端构建产物部署到Nginx的location /api/路径完美匹配——这种环境配置的对齐，比写一百行文档都管用。

3. 核心功能模块实现与关键技术细节

3.1 Spring Security + JWT权限控制的完整链路

这套系统的权限控制不是“能用就行”，而是经得起推敲的工业级实现。我们从用户登录开始，一步步拆解JWT令牌如何贯穿整个请求生命周期。

登录接口LoginController.login()接收{username: "admin", password: "123"}，核心逻辑只有三步：第一，调用UserDetailsServiceImpl.loadUserByUsername()从数据库查用户（这里会加载用户的角色列表和权限列表）；第二，用BCryptPasswordEncoder比对密码；第三，调用JwtTokenUtil.generateToken()生成JWT。这个生成过程很关键：generateToken()方法里，Claims对象不仅塞入username和userId，还显式加入roles（角色数组）和permissions（权限字符串集合），比如["ROLE_admin", "ROLE_hr"]和["emp:list", "emp:detail", "salary:read"]。这样做的好处是，后续每次请求都不需要查数据库就能完成权限校验——Token本身就是一个自包含的凭证。

Token生成后，后端返回{token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}，前端存入localStorage，并在后续所有请求头里带上Authorization: Bearer <token>。关键的过滤器JwtAuthenticationFilter开始工作：它继承OncePerRequestFilter，确保每个请求只执行一次；重写doFilterInternal()方法，先从request.getHeader("Authorization")提取Token，再用Jwts.parser().setSigningKey(secret).parseClaimsJws(token)解析。如果解析失败（比如密钥错误、过期），直接response.sendError(HttpServletResponse.SC_UNAUTHORIZED)；如果成功，就从claims.get("permissions", List.class)取出权限列表，创建UsernamePasswordAuthenticationToken并设置到SecurityContextHolder.getContext().setAuthentication()里。

到这里，Spring Security的上下文已经准备好，接下来就是权限校验。EmployeeController的方法上写着@PreAuthorize("hasAuthority('emp:update')")，这个注解触发PreInvocationAuthorizationAdvice，它会检查当前Authentication对象的getAuthorities()是否包含SimpleGrantedAuthority实例，其getAuthority()返回值等于"emp:update"。注意，这里的hasAuthority不是检查角色（hasRole），而是检查权限字符串，因为我们在JWT里存的就是permissions数组，而不是roles数组——这是细粒度控制的基础。

但光有方法级校验还不够，前端按钮也要同步隐藏。这时候kfk-web模块的SysMenuController.listByUserId()就派上用场了：它根据用户ID查出所有可访问的菜单项（sys_menu表），再关联查出每个菜单下的按钮权限（sys_menu_permission表），最终返回一个树形结构。前端store/modules/menu.js里loadMenu() action调用这个接口，把结果存入Vuex，components/Sidebar.vue里用v-for遍历渲染菜单，v-if="item.permissions.includes('emp:add')"控制按钮显示。这种“后端控制接口访问，前端控制UI展示”的双重保险，才是企业级权限系统的标配。

3.2 Vue2前端权限路由与动态菜单的实现原理

Vue2的路由权限控制，很多人卡在“如何动态添加路由”这一步。这套源码用了一个非常巧妙的方案：先注册所有路由，再用meta字段控制显示，而不是用router.addRoutes()动态追加——后者在Vue Router 3.x里有坑，比如路由守卫不生效、导航守卫顺序混乱。

所有路由定义在router/index.js里，但关键在于每个路由的meta属性：

{
  path: '/employee',
  name: 'Employee',
  component: () => import('@/views/employee/index.vue'),
  meta: {
    title: '员工管理',
    icon: 'el-icon-user',
    requiresAuth: true,
    permissions: ['emp:list', 'emp:detail']
  }
}

requiresAuth告诉全局守卫需要登录，permissions数组则记录该页面所需的最小权限集。登录成功后，store/modules/user.js里的login action除了存token，还会调用dispatch('menu/loadMenu')，这个action发起请求到/api/menu/list，后端返回的菜单数据结构是：

[
  {
    "id": 1,
    "name": "员工管理",
    "path": "/employee",
    "icon": "el-icon-user",
    "children": [
      {"id": 2, "name": "员工列表", "path": "/employee/list", "permissionCode": "emp:list"},
      {"id": 3, "name": "员工详情", "path": "/employee/detail", "permissionCode": "emp:detail"}
    ]
  }
]

前端收到后，不是直接替换路由，而是遍历这个菜单树，对每个节点检查state.user.permissions.includes(node.permissionCode)，只有满足权限的节点才保留。然后用router.options.routes里的原始路由配置，根据菜单节点的path找到对应的路由对象，将其meta.hidden = false，其余不匹配的路由设为meta.hidden = true。这样，Sidebar.vue里v-for="route in $router.options.routes"时，通过v-if="!route.meta.hidden && route.meta.title"就能精准渲染有权限的菜单。

按钮级权限更进一步。源码里封装了<auth-button>组件，它接收code属性（如"emp:delete"），在mounted()钩子里调用this.$store.getters.hasPermission(code)，这个getter从state.user.permissions数组里查找。如果找不到，就用v-show="false"隐藏按钮；如果找到，则正常渲染。这样做的好处是，即使用户手动修改DOM显示了按钮，点击时后端接口依然会返回403——前后端权限校验形成闭环。

3.3 MySQL人事数据库设计的实用性考量

vhr.sql脚本不是随便写的，每一张表、每一个字段都对应着真实业务场景。我们来看几个关键设计点：

sys_user表里，password字段类型是varchar(100)，而不是char(64)。这是因为BCrypt加密后的密码长度是可变的（通常60字符左右），固定长度会导致截断风险。enabled字段用tinyint(1)存储布尔值，但值是0或1，而不是true/false——这是MySQL的惯用法，避免Java端Boolean类型映射出错。avatar字段存的是头像URL相对路径（如/upload/avatar/123.jpg），而不是二进制数据，既节省数据库空间，又方便CDN加速。

sys_role和sys_user_role的多对多关系设计得很干净。sys_user_role表只有user_id和role_id两个字段，没有多余的时间戳或状态字段——因为角色分配是即时生效的，不需要历史追溯。但sys_role_menu表多了menu_id和role_id，用来控制角色能看到哪些菜单。这里有个细节：sys_menu表里component字段存的是Vue组件路径（如'@/views/employee/index.vue'），这样后端返回菜单数据时，前端可以直接用import()动态导入组件，不需要额外维护组件名映射表。

最体现功力的是sys_menu_permission表。它不是简单地存“菜单ID+权限码”，而是有menu_id、permission_code、permission_name三个字段。permission_code是机器可读的字符串（如"emp:export"），permission_name是人类可读的名称（如“导出员工”）。这样做的好处是，后端接口文档可以用permission_name生成中文说明，前端按钮文案也可以直接用它，避免硬编码。而且，当你要给某个角色分配“导出员工”权限时，只需要往这张表里插入一行，不需要修改任何代码——权限体系真正做到了可配置。

4. 实操部署与二次开发全流程详解

4.1 从零开始部署：MySQL、后端、前端三步走

部署这套系统，我建议严格按顺序操作，跳过任何一步都可能踩坑。以下是我在客户现场验证过的标准流程：

第一步：MySQL初始化
下载vhr.sql脚本，用MySQL Workbench或命令行执行：

mysql -u root -p < vhr.sql

注意，脚本里默认创建的数据库名是vhr，字符集是utf8mb4。如果你的MySQL版本低于5.7.7，需要手动修改脚本开头的CREATE DATABASE IF NOT EXISTS vhr DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;为utf8。执行后，检查sys_user表里是否有初始账号：admin/admin和hr/hr。这两个账号的密码都是BCrypt加密过的，不要试图用明文密码登录——它们是系统预置的测试账号。

第二步：后端启动
进入kfkserver目录（不是根目录！），执行：

mvn clean package -Dmaven.test.skip=true
java -jar target/kfk-server-1.0-SNAPSHOT.jar --spring.profiles.active=prod

这里的关键参数--spring.profiles.active=prod会激活application-prod.yml配置，里面指定了spring.datasource.url=jdbc:mysql://localhost:3306/vhr?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai。如果你的MySQL端口不是3306，或者数据库名不是vhr，必须在这里修改。启动成功后，访问http://localhost:8080/swagger-ui.html，能看到Swagger文档界面——这是验证后端是否正常工作的最快方式。

第三步：前端构建与部署
进入根目录（有package.json的那个），先安装依赖：

npm install

然后启动开发服务器：

npm run serve

此时前端运行在http://localhost:8081，后端在http://localhost:8080，由于vue.config.js里配置了代理，所有/api/**请求都会转发到8080端口。如果要构建生产环境包，执行：

npm run build:prod

生成的dist目录里是纯静态文件，把它复制到Nginx的html目录下，配置Nginx：

location /api/ {
    proxy_pass http://localhost:8080/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

这样，访问http://your-domain.com时，前端静态资源由Nginx直接返回，API请求则反向代理到后端。

4.2 二次开发避坑指南：改哪里？怎么改？改完怎么测？

二次开发最容易犯的错误，就是“哪都能改，但改完就崩”。我总结了三个安全区和三个雷区：

安全区一：新增业务模块
比如你要加一个“考勤管理”模块。正确做法是：
1. 在kfk-model里新建Attendance.java实体类，字段包括employeeId、date、status（0=缺勤，1=正常，2=迟到）；
2. 在kfk-mapper里新建AttendanceMapper.java接口和AttendanceMapper.xml，写好CRUD SQL；
3. 在kfk-service里新建AttendanceService.java，实现业务逻辑（如“统计某月出勤率”）；
4. 在kfk-server里新建AttendanceController.java，用@PreAuthorize("hasAuthority('attendance:list')")标注权限；
5. 前端在src/views/attendance/下新建页面，路由配置里加上meta: { permissions: ['attendance:list'] }；
6. 最后，在vhr.sql里执行INSERT INTO sys_menu (...) VALUES (...); INSERT INTO sys_menu_permission (...) VALUES (...);。

这样新增的模块，完全遵循原有架构，不会影响其他功能。

安全区二：调整权限配置
想让HR专员也能审核请假申请？不需要改代码，只需操作数据库：
1. 查sys_permission表，找到请假审核的权限码（如"leave:approve"）；
2. 查sys_role表，找到HR专员的角色ID（如2）；
3. 向sys_role_permission表插入一行：(2, 权限ID)。

安全区三：修改前端样式
src/assets/styles/variables.scss里定义了所有主题变量（如$primary-color: #409EFF;），改这里就能全局换色。src/components/common/下的通用组件（如Pagination.vue）也支持props传入样式，比如<pagination :background="true" />。

雷区一：直接修改kfk-web里的Controller
比如你想在EmployeeController里加个日志打印，写System.out.println("xxx")。这看起来无害，但kfk-web模块的职责只是接收请求和返回响应，业务逻辑必须下沉到kfk-service。否则，当你把kfk-web打包成独立war包部署时，这些日志代码就成了冗余负担。

雷区二：在Vue组件里写业务逻辑
src/views/employee/detail.vue里，不要写this.$http.post('/api/salary/update', {...})这种直接调用API的代码。所有API请求必须封装在src/api/employee.js里，比如export function updateSalary(data) { return request({ url: '/salary/update', method: 'post', data }) }。这样做的好处是，当后端API路径变更时，你只需要改一个地方。

雷区三：忽略README.md里的环境变量说明
README.md里写了# 后端配置：application-prod.yml中需修改数据库连接地址，但很多人直接用默认配置。结果就是启动时报Communications link failure。记住，application-prod.yml里的spring.datasource.username和password必须和你的MySQL账号密码一致，url里的localhost要改成实际数据库IP。

5. 常见问题排查与独家调试技巧

5.1 启动报错：Failed to configure a DataSource怎么办？

这是新手最常见的报错，表面看是数据库配置问题，但根源往往在pom.xml的依赖冲突。比如你在kfk-server/pom.xml里不小心加了两个不同版本的mysql-connector-java：

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.28</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.47</version>
</dependency>

Maven会取高版本，但Spring Boot 2.3.x默认兼容的是8.0.x，而5.1.x的驱动类名是com.mysql.jdbc.Driver，8.0.x是com.mysql.cj.jdbc.Driver。解决方案是：用mvn dependency:tree | grep mysql查看实际引入的版本，然后在<dependencyManagement>里锁定版本：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.28</version>
        </dependency>
    </dependencies>
</dependencyManagement>

5.2 登录成功但菜单不显示？检查JWT解析是否失败

前端登录后，F12看Network标签页，/api/menu/list接口返回空数组。这时不要急着查前端代码，先看后端日志。如果日志里有io.jsonwebtoken.security.SignatureException: JWT signature does not match locally computed signature，说明JWT密钥不匹配。JwtTokenUtil里的secret字段必须和application-prod.yml里的jwt.secret完全一致。更隐蔽的问题是：application-prod.yml里jwt.secret=abc123，但Java代码里写的是private static final String SECRET = "abc123 ";——末尾多了一个空格，肉眼很难发现。

5.3 权限校验失效？确认@EnableGlobalMethodSecurity是否启用

kfk-server模块的主启动类KfkServerApplication.java上，必须有@EnableGlobalMethodSecurity(prePostEnabled = true)注解。这个注解是@PreAuthorize生效的前提。如果忘了加，所有@PreAuthorize都会静默失效，接口能被任意调用。检查方法很简单：在EmployeeController里加个@PreAuthorize("hasAuthority('xxx')")，然后用curl调用，如果返回200而不是403，基本就是这个注解没启用。

5.4 前端路由404？Vue Router模式与Nginx配置不匹配

开发时用npm run serve没问题，但构建后部署到Nginx，访问/employee返回404。这是因为Vue Router默认用history模式，需要Nginx配置try_files $uri $uri/ /index.html;。但很多人只配了：

location / {
    root   html;
    index  index.html index.htm;
}

缺少try_files指令。正确配置是：

location / {
    root   html;
    index  index.html index.htm;
    try_files $uri $uri/ /index.html;
}

这样，当Nginx找不到/employee这个静态文件时，就会返回index.html，由Vue Router接管路由。

5.5 数据库中文乱码？检查MySQL全局配置

vhr.sql里建表语句有DEFAULT CHARSET=utf8mb4，但如果MySQL服务器的character_set_server不是utf8mb4，依然会乱码。登录MySQL执行：

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

如果character_set_server是latin1，需要修改my.cnf：

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
[client]
default-character-set=utf8mb4

然后重启MySQL。重启后，用SHOW CREATE TABLE sys_user;确认表字符集已生效。

6. 学习路径建议与能力跃迁地图

这套源码的价值，不在于“能跑起来”，而在于它是一张清晰的能力跃迁地图。我建议按这个顺序吃透它：

第一阶段：跑通+理解（1-3天）
目标是让系统在本地跑起来，并理解每个模块的作用。重点做三件事：1）照着README部署，记录每一步的命令和输出；2）用IDEA打开kfk-server，在EmployeeController的list()方法上打个断点，用Postman发请求，观察断点停在哪、变量值是什么；3）在Chrome里打开Vue Devtools，切换到Vuex标签页，看state.user里有哪些字段。这个阶段不要求懂原理，只要建立“代码-功能”的直观联系。

第二阶段：修改+验证（3-7天）
目标是能独立修改功能并验证效果。任务清单：1）给员工列表加一个“入职年份”列，需要改Employee.java加字段、EmployeeMapper.xml加SQL、EmployeeController加返回字段、前端employee/list.vue加表格列；2）把登录页的Logo换成自己的图片，改public/logo.png和src/App.vue里的img路径；3）新增一个“部门统计”图表，用ECharts实现，数据从/api/dept/stats接口获取。这个阶段的关键是“小步快跑”，每次只改一个点，立刻验证。

第三阶段：重构+扩展（1-2周）
目标是理解架构意图，并能按规范扩展。挑战任务：1）把kfk-server模块拆分成kfk-employee-server和kfk-salary-server两个独立服务，用FeignClient通信；2）把JWT认证换成OAuth2.0，集成GitHub登录；3）给所有API增加OpenAPI 3.0文档，用springdoc-openapi替代Swagger。这个阶段你会开始思考“为什么原来这么设计”、“换成新方案要改哪些地方”，这才是架构师思维的起点。

最后分享一个小技巧：在kfk-server/src/main/resources/application-dev.yml里，把logging.level.com.kfk=DEBUG打开，这样所有自定义日志（如log.debug("查询员工列表，参数：{}", query)）都会打印出来。比打断点更高效，尤其适合排查权限校验流程——你能在日志里看到“用户admin的权限列表：[emp:list, emp:detail]”，然后马上知道为什么某个按钮没显示。

这套源码就像一把瑞士军刀，初学者用它学全栈，中级开发者用它练架构，高级工程师用它搭脚手架。它不追求炫技，但每个细节都经得起推敲。当你能把vhr.sql里的每张表、pom.xml里的每个依赖、vue.config.js里的每个配置都讲清楚为什么这么写时，你就已经超越了90%的Java/Vue开发者。

本文还有配套的精品资源，点击获取

简介：这套人事管理系统源码采用前后端分离架构，后端基于SpringBoot 2.x（Java语言），整合MyBatis做数据持久化，Spring Security + JWT实现登录认证与权限控制；前端使用Vue 2.x（非Vue3），包含完整路由配置、角色权限拦截、组件化页面及响应式布局；配套vhr.sql数据库脚本，适配MySQL一键导入；项目按标准分层组织：kfk-model（实体类）、kfk-mapper（DAO接口与XML映射）、kfk-service（业务逻辑）、kfk-web（Controller层）、kfk-server（服务聚合层），结构清晰便于理解与扩展；提供vue.config.js、babel.config.js、package.、pom.xml等全套构建配置文件，以及README.md使用说明和MIT授权的LICENSE文件；适合Java/Vue初学者学习全栈开发流程，也支持企业内部快速二次开发或教学演示。

本文还有配套的精品资源，点击获取