1. 为什么中小企业需要一套自己的“人事管理系统”做这个项目之前我先说个现象。很多中小型公司员工规模从几十人到两三百人不等人事管理基本靠Excel表格、微信消息、纸质审批单凑合着跑。员工入职填一张纸质登记表——录入HR的电脑——月底财务照着表格算工资——考勤情况靠部门主管月底口头汇报一声。表面上看能用但你真去问HR她一定有一肚子苦水员工信息散落在好几个版本的Excel里改了一个忘记同步另一个请假审批在微信里聊完了月底对不上数薪资变动没有留痕员工来问工资构成解释半天也没依据。我做过好几套类似的系统这套基于SpringBootVue的中小企业人事管理系统算是其中功能覆盖比较完整的一套。技术栈就是标题里写的后端SpringBoot做接口服务前端Vue做管理页面MySQL存数据MyBatis负责数据库访问源码里已经把登录认证、员工管理、部门管理、岗位管理、考勤管理、薪资管理、公告管理这些模块都实现了。如果你是做Java开发的大学生、刚转行的初级工程师或者公司HR想要一套能内部跑起来的人事工具这篇文章值得看完。我会把项目的模块设计、数据库表结构、核心代码写法、部署方式全部拆开讲包括源码里那些光看代码看不出来的设计取舍。为什么我强调中小企业这个限定词因为大企业人事系统通常是saas平台或者定制化EHR系统功能极其庞杂——绩效、培训、招聘、社保公积金、薪酬套账、组织架构调整留痕光权限模型就能写几百页文档。但中小企业的诉求完全不一样数据要集中、流程要简单、操作要直观、成本要可控。用企业微信Excel不是不行但数据孤岛严重每次统计都是重复劳动直接用SaaS人事平台按人头收费几十人一年下来也要几千块还未必符合自己公司的管理习惯。这套系统的定位就是一个普通Java开发者在1-2周内能完成开发、能部署在内网服务器上、业务逻辑符合大多数中小企业管理习惯的人事管理系统。功能不求大而全但求每个模块都能真正用起来。下面我从设计思路到落地细节把整个项目从头到尾讲一遍。2. 技术选型的底层逻辑这套组合为什么能打2.1 SpringBoot中小型管理系统最省心的后端底座后端选SpringBoot在Java技术圈基本不用犹豫。相比传统的SSHSpringStrutsHibernate或者Spring MVC的XML配置时代SpringBoot最大的价值是把配置地狱变成了约定优于配置。你新建一个项目引入spring-boot-starter-web写一个RestController一个main方法启动——一个能跑起来的HTTP服务就完成了。这对中小企业管理系统来说太重要了因为这类系统的复杂度主要在业务逻辑上而不是在框架配置上。具体到人事系统SpringBoot带来的直接好处有三个第一内嵌Tomcat部署成本低。以前部署一个JavaWeb项目要单独装Tomcat、配置数据源、扔war包。SpringBoot直接打成可执行jar包服务器上装个JDKjava -jar就能跑。中小企业没有专职运维这种部署方式几乎不考验IT基础。第二Starter生态完备。集成MyBatis有mybatis-spring-boot-starter操作MySQL有mysql-connector-java做鉴权有spring-boot-starter-security或者自己写拦截器。权限校验、参数校验、异常处理这些常见需求全都有现成的组件可以接开发效率提升非常明显。第三测试和排查方便。SpringBoot的自动配置在启动日志里会打印当前生效的配置项出问题时用spring-boot-starter-actuator可以看健康状态、接口映射列表。对于这套系统要交给别人维护的场景这个特性非常加分。2.2 Vue让HR和管理层愿意用起来的关键前端选Vue同样是在国内中小型管理系统里最成熟的选择。我见过太多后端工程师硬写jQuery页面功能实现了但界面丑、操作卡顿HR用两天就抱怨还不如用Excel。管理系统的成败很多时候不在功能而在体验。Vue的核心优势是数据驱动视图。比如员工列表页搜索条件变了、页数切换了、某行数据被修改了你只需要更新对应的data数据页面自动重新渲染完全不需要手动操作DOM。这对表单密集、列表密集的管理系统是刚需。再配合ElementUI组件库表格、表单、弹窗、分页、日期选择器这些后台管理场景的高频组件开箱即用开发速度非常快。很多人纠结一个问题用Vue2还是Vue3这套系统源码用的是Vue2配合ElementUI原因很现实——Vue2 ElementUI 各种第三方库的搭配经过大量项目验证资料多、坑少对刚接触前后端分离开发的新手更友好。你在网上搜vue管理系统模板绝大多数能直接跑通的都是Vue2版本。如果你愿意花时间踩坑Vue3 Element Plus Vite当然更好但对于这套系统的定位——完整可运行、方便二次开发——Vue2是最稳的选择。2.3 MyBatis MySQL轻量、可控、贴近业务直觉持久层用MyBatis数据库用MySQL这也是Java中小型项目最经典的搭配。我经常被问到为什么不用MyBatis-Plus或者JPA老实说MyBatis-Plus的开发效率确实更高用LambdaQueryWrapper写查询基本不用手写SQL。但这个项目之所以用原生MyBatis一个重要原因是这个项目具备教学和源码参考价值。当你用原生MyBatis写完整个项目你会对SQL映射、动态SQL、ResultMap、多表联查有非常扎实的理解。这些知识是Java后端工程师的底层能力换到MyBatis-Plus只是换了个更省事的工具但底层逻辑没变。MySQL的选择则完全是行业共识。中小企业内部系统数据量撑死在百万行以内MySQL完全覆盖得住且开源免费部署运维资料丰富。MySQL的InnoDB引擎支持事务人事数据尤其是薪资、合同这类敏感数据必须保证写入的原子性。2.4 这套组合的整体架构图景整个系统的请求链路是这样的浏览器Vue页面→ HTTP请求 → Nginx部署前端静态资源反向代理 → SpringBoot接口层 → Service业务层 → MyBatisMapper接口XML → MySQL数据库开发环境下前端通过Vue CLI的devServer代理转发请求到后端8080端口避免跨域问题生产环境下Nginx将/api/前缀的请求转发到后端服务。这个架构是当前中小型前后端分离项目的主流标准学会了这个架构你以后做任何内部管理系统都能直接套用。3. 系统功能模块拆解从一堆数据表看人事系统的真实复杂度3.1 模块地图先理清系统到底要管什么一套合格的中小企业人事系统至少得覆盖以下六个模块。我把这套系统的模块划分整理成表你对照着自己的公司需求看哪些要改、哪些能直接用模块核心功能对应数据表业务说明系统登录/权限JWT认证、用户角色、菜单权限sys_user, sys_role, sys_menu区分管理员、HR、普通员工三种角色员工管理员工信息CRUD、条件搜索、状态拉黑employee系统的核心主数据其他模块都引用它部门与岗位部门树形结构、岗位职位管理department, position部门上下级关系岗位挂在部门下考勤管理打卡记录、请假申请、加班调休attendance, leave, overtime和员工表、审批流关联最为频繁薪资管理基本工资、奖金、扣款、实发计算salary和考勤联动月底批量生成公告管理公告发布、查看列表、置顶删除notice全员可见消息触达用这六个模块拆完你再看会不会很复杂这个问题就会发现其实每个模块单独拿出来都不复杂复杂的是模块之间的数据如何关联权限如何控制以及每个功能的边界应该划在哪里。3.2 数据库设计的核心员工表就是整个系统的“心脏”一个系统的数据库设计好不好看主表就能判断。员工表employee的字段设计直接决定了后续考勤、薪资、异动这些功能能否顺畅实现。下面是我在这套系统里使用的employee表核心字段设计为了排版做了精简CREATE TABLE employee ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 员工ID, empno varchar(20) NOT NULL COMMENT 工号, name varchar(50) NOT NULL COMMENT 姓名, gender tinyint(1) DEFAULT NULL COMMENT 性别 1男 0女, birthday date DEFAULT NULL COMMENT 出生日期, idcard varchar(18) DEFAULT NULL COMMENT 身份证号, phone varchar(20) DEFAULT NULL COMMENT 手机号, email varchar(50) DEFAULT NULL COMMENT 邮箱, dept_id int(11) DEFAULT NULL COMMENT 所属部门ID, position_id int(11) DEFAULT NULL COMMENT 岗位ID, entry_date date DEFAULT NULL COMMENT 入职日期, education varchar(20) DEFAULT NULL COMMENT 学历, status tinyint(1) DEFAULT 1 COMMENT 在职状态 1在职 0离职, remark varchar(500) DEFAULT NULL COMMENT 备注, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY idx_empno (empno) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT员工信息表;几个设计要点我特别说一下工号用unique约束业务上天然唯一。中小公司里员工的工号通常由HR手动分配或者按年份序号生成。这里加上唯一索引是防止重复录入。身份证号存明文还是加密这个要分场景。系统如果部署在纯内网明文存储影响不大但如果要暴露到公网建议至少用AES或者BCrypt做加密处理。源码里目前是明文存储方便演示和二次开发你落地到生产环境时一定要评估这个风险。status字段不用delete而是用状态标记。员工离职不是删除数据——历史考勤、历史薪资都要关联这个人。所以用status0表示离职列表查询时默认过滤掉离职员工但统计报表要能查回来。这个设计几乎所有的管理系统都适用。create_time和update_time一定不要省。后端很多业务排查都需要看数据什么时候被创建、什么时候被修改。MySQL的DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP能自动维护这两个字段成本为零。3.3 部门表的经典写法递归树形结构部门表department的难点在于层级关系。中小企业组织架构一般是2-3层——公司下面分技术部、市场部、行政部技术部下面可能再分一组、二组。用数据表表达这种关系最常见的就是parent_id自关联。CREATE TABLE department ( id int(11) NOT NULL AUTO_INCREMENT, parent_id int(11) DEFAULT 0 COMMENT 上级部门ID0表示根节点, name varchar(50) NOT NULL COMMENT 部门名称, leader varchar(50) DEFAULT NULL COMMENT 负责人, sort_order int(11) DEFAULT 0 COMMENT 排序号, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT部门表;查询的时候前端部门树组件需要树形数据。后端返回一个扁平List前端递归构建Children也可以后端用递归查询直接返回嵌套结构。我在源码里是后端构建好树形结构返回的因为部门层级不深递归查询的性能完全不是问题。常见的坑是删除部门时没有检查部门下面有没有员工。如果直接删掉一个还有员工关联的部门员工表的dept_id就变成悬空引用了。处理办法是删部门前先count一下员工数有人的部门不允许删除提示该部门下还有员工请先调整员工部门。这一条在代码里必须有实测很多低年级开发者会漏。3.4 考勤和薪资联动最容易跑偏的业务逻辑考勤和薪资是整套系统里业务逻辑最复杂的两个模块也是很容易被做成看起来不错但实际没法用的典型。先说考勤。中小企业考勤方式通常是钉钉/美团打卡机 月底人工统计。这套系统里考勤模块提供三个子功能打卡记录维护手动新增、编辑员工某天的打卡时间请假申请员工提交请假单开始日期、结束日期、请假类型、事由HR审批加班登记记录加班时长用于后续调休或加班费计算注意这套系统没有对接硬件打卡机原因是对接硬件涉及硬件SDK和API适配不同牌子兼容性差异很大不适合作为通用demo。你要在实际项目中接入钉钉考勤或指纹机数据一般是在这个模块基础上扩展数据导入功能——Excel导入打卡记录或者调用钉钉开放平台的考勤接口同步数据。再说薪资。薪资计算的核心逻辑是应发工资 基本工资 绩效奖金 加班费 - 社保扣款 - 考勤扣款。源码里的salary表设计大致是这样的CREATE TABLE salary ( id int(11) NOT NULL AUTO_INCREMENT, emp_id int(11) NOT NULL COMMENT 员工ID, year_month varchar(7) NOT NULL COMMENT 工资月份 如2025-06, base_salary decimal(10,2) DEFAULT NULL COMMENT 基本工资, bonus decimal(10,2) DEFAULT 0.00 COMMENT 绩效/奖金, overtime_pay decimal(10,2) DEFAULT 0.00 COMMENT 加班费, social_insurance decimal(10,2) DEFAULT 0.00 COMMENT 社保扣款, attendance_deduct decimal(10,2) DEFAULT 0.00 COMMENT 考勤扣款, total_salary decimal(10,2) DEFAULT NULL COMMENT 实发工资, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_emp_month (emp_id, year_month) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT薪资表;注意uk_emp_month这个联合唯一索引——一个员工一个月只能有一条薪资记录这从根本上避免了重复发工资的数据问题。薪资是否要和考勤自动联动比如请假一天扣200迟到三次扣50。这个需求很常见但我不建议在通用系统里做死逻辑。因为每家公司的考勤扣款规则差异极大有的公司按小时扣有的按次扣还有的每月允许迟到三次不计较。源码里的做法是考勤模块统计异常情况薪资模块手动录入扣款金额。想做自动联动的人可以在现有表结构上扩展一个扣款规则配置表但这属于二次开发范畴了。3.5 权限模型三个角色够用就好权限设计在管理系统里是个无底洞——RBAC、菜单权限、按钮权限、数据权限复杂起来没完。针对中小企业人事系统我建议把权限做简单三种角色角色-菜单绑定。admin管理员拥有全部菜单权限可以管理所有模块包括角色分配和用户创建hrHR专员拥有员工管理、考勤管理、薪资管理、部门管理权限公告可以发布employee普通员工只能看到公告、个人信息、自己的考勤记录和请假申请前后端权限控制是双层配合的后端用SpringMVC拦截器拦截请求校验JWT令牌中携带的用户角色然后判断请求的URL是否在该角色允许的权限列表里不允许直接返回403。前端根据登录后返回的菜单列表动态渲染侧边栏没有权限的菜单根本不会显示。注意前端控制只是体验优化后端校验才是安全底线——不过前端隐藏菜单经常被人当成安全控制用这是错误的任何接口只要调通了就能拿到数据。权限明细存在sys_role_menu关联表里一个角色对应多个菜单ID。如果你改了菜单表里的新增菜单只需要在sys_role_menu里给对应角色插入一条记录即可不需要改代码。4. 核心功能模块的代码落地与设计取舍4.1 JWT登录认证为什么不建议用Session登录认证这块我直接选了JWTJSON Web Token。原理很简单用户登录成功后后端根据用户信息生成一个JWT令牌本质上是一段经过签名加密的JSON数据返回给前端。前端每次请求在Header里带上Authorization: Bearer 后端拦截器解析token能解析出来就放行解析失败就返回401。相比Session方案JWT有两张王牌在使用时就会体会到第一无状态天然适合前后端分离。Session方案要求服务端保存会话信息如果做了负载均衡两台服务器轮询Session需要单独存到Redis里共享。JWT本身携带用户信息任何一台服务器都能独立校验不需要共享存储。第二移动端友好。同一个后端接口Web端和App端都可以通过JWT接入不需要做额外的会话适配。但JWT也有它自己的坑最大的就是过期时间设置。过期时间太短——比如30分钟用户操作一会儿就被强制下线体验很差太长——比如7天token泄露了风险也大。源码里的方案是设置24小时过期加上前端在收到401时自动跳转登录页实际体验下来是能接受的。更完善的方案是RefreshToken机制但这就属于进阶优化了源码里没做原因是不想过度设计。登录接口的核心逻辑如下RestController RequestMapping(/api/auth) public class AuthController { PostMapping(/login) public Result login(RequestBody LoginDTO loginDTO) { // 1. 根据用户名查询用户 SysUser user sysUserMapper.selectByUsername(loginDTO.getUsername()); // 2. 校验密码BCrypt加密比对 if (user null || !BCrypt.checkpw(loginDTO.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } // 3. 生成JWT带上用户ID和角色 String token JwtUtil.generateToken(user.getId(), user.getUsername(), user.getRole()); // 4. 查询当前用户的菜单权限列表用于前端渲染侧边栏 ListMenuVO menus menuMapper.selectMenusByRole(user.getRole()); return Result.success(new LoginVO(token, menus, user.getName())); } }很多新手容易忽略第4步——登录接口返回菜单列表。这一步省了前端就得再单独调一次权限接口而且首次进入系统时菜单渲染会白屏闪烁。登录时一次性把菜单带回去前端拿到token和menus直接初始化状态体验会好很多。4.2 部门树查询递归在业务代码里的标准姿势部门树是管理系统的常见需求代码写法很固定。我给出一段从后端构建树形结构的核心逻辑public ListDepartmentVO buildDeptTree(ListDepartment allDepts) { // 转成VO扩展children字段 ListDepartmentVO voList allDepts.stream().map(DepartmentVO::new).collect(Collectors.toList()); ListDepartmentVO tree new ArrayList(); // 先找出所有根节点然后递归挂载子节点 for (DepartmentVO dept : voList) { if (dept.getParentId() 0) { tree.add(dept); } } for (DepartmentVO root : tree) { findChildren(root, voList); } return tree; } private void findChildren(DepartmentVO parent, ListDepartmentVO allDepts) { for (DepartmentVO dept : allDepts) { if (parent.getId().equals(dept.getParentId())) { parent.getChildren().add(dept); findChildren(dept, allDepts); // 递归往下找 } } }这段代码的核心思路是先建森林再挂树枝。第一次循环找根部门parent_id 0第二次递归给每个根部门找儿子、给儿子找孙子。数据量在几百个部门以内这种写法完全够用不需要上什么复杂的算法。前端Vue这边ElementUI的el-tree控件直接支持树形数据渲染把后端返回的JSON扔进去写上:props{ label: name, children: children }就能展示。前后端字段名必须保持严格一致children是后端定义好的这个约定要提前想清楚不然后端返回了children前端却不认识白白浪费半小时。4.3 员工信息管理CRUD之外的三个细节员工管理模块的增删改查本身很简单但有几个细节处理得好不好直接拉开能用和好用的差距。搜索条件的分页查询要支持组合条件。员工列表页通常有搜索栏——姓名、部门、状态、入职时间范围。我的做法是在Mapper XML里写动态SQLselect idpageQuery resultTypecom.example.entity.Employee SELECT * FROM employee where if testname ! null and name ! AND name LIKE CONCAT(%, #{name}, %) /if if testdeptId ! null AND dept_id #{deptId} /if if teststatus ! null AND status #{status} /if /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select注意where标签的用法——它自动处理条件前缀AND当所有条件都不满足时不带WHERE子句。MyBatis动态SQL是原生的核心技能我强烈建议手写比依赖工具自动生成的代码可靠得多也更容易调试。出生日期和身份证号码的关联校验。员工录入表单里填写身份证号后自动提取出生日期和性别。这属于锦上添花的功能但HR真实使用时会觉得很贴心。实现就是在前端通过JS解析身份证号第7-14位是出生日期倒数第二位奇偶决定性别自动填到日期字段和性别字段里禁用手动修改。离职状态的管理。员工离职不是直接删除而是修改status为0。薪资表里如果还在计算这个员工就应在快照的时候就判断状态。一个简便方案薪资生成页面只加载在职员工列表离职的人不会再被选中。这个逻辑简单直接不容易出现给离职员工照发工资的bug。4.4 薪资管理模块用“按月快照”思路规避数据变化风险薪资管理模块有一个很容易被忽视但非常重要的设计——薪资数据的快照特性。什么叫快照就是你发的是入职时定的工资还是这个月实际工资。员工升职加薪后基本工资变了但你不可能把上个月的工资记录也改掉。薪资表里的base_salary是生成工资记录那一刻的金额不是实时从员工表反查的。这种开户容易销毁困难的数据处理方式必须业务明确工资单生成后不允许修改只能在当月发工资之前通过撤销重算或者手动订正来处理。源码里这一点也比较直白——薪资表没有关联薪资标准表就是月末录入的时候直接填金额。这样做的好处是简单灵活符合中小企业实际很多公司的薪资本来就是见面的坏处是没有调薪记录的完整链路。如果你需要做调薪管理可以给员工表加一个current_salary字段再新增一张salary_adjust_record表记录每一次调薪的金额、时间、原因形成完整审计链。4.5 统计报表与Excel导出后端工程师的隐藏加分项最后提一下报表模块。管理系统里列表做得花哨不如能导出一张格式干净的Excel。HR月底要给老板发各部门人数统计本月入离职情况如果系统不能导出Excel她就得截图或者手动抄表体验大打折扣。这套系统里Excel导出的实现方式是使用Apache POI在后台把查询结果写入Workbook然后通过HttpServletResponse以流的形式输出。核心逻辑很简单// 构造Excel对象 XSSFWorkbook workbook new XSSFWorkbook(); XSSFSheet sheet workbook.createSheet(员工信息); XSSFRow header sheet.createRow(0); header.createCell(0).setCellValue(工号); header.createCell(1).setCellValue(姓名); // ...填充其他列 // 遍历数据逐行写入 for (int i 0; i list.size(); i) { XSSFRow row sheet.createRow(i 1); row.createCell(0).setCellValue(list.get(i).getEmpno()); // ... } // 设置响应头浏览器自动下载 response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet); response.setHeader(Content-Disposition, attachment; filenameemployee.xlsx); workbook.write(response.getOutputStream());POI虽然引入后项目会多几MB依赖但导Excel是管理系统的刚需这依赖加得值。而且注意Excel文件名最好加上日期如员工信息_20250620.xlsx否则HR每天导出一份文件文件名全叫employee很快磁盘就会堆满一堆同名文件。5. 从源码到上线环境准备与部署避坑实录5.1 本地开发环境搭建拿到源码后很多人第一步就卡在环境上。我把需要准备的东西列一个清单按顺序装完直接能跑JDK 1.8推荐8或11不要用17除非你改过pom里的依赖版本Maven 3.6MySQL 5.7推荐8.0兼容性更好Node.js 14Vue2的Vue CLI需要IDE后端用IDEA前端用VSCode或者IDEA都行数据库初始化的步骤是这样的用Navicat或命令行创建数据库CREATE DATABASE hr_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;导入源码中sql目录下的hr_system.sql文件里面有建表语句和基础数据包括默认的管理员账号。修改后端application.yml里的数据库连接配置把用户名密码改成你自己的spring: datasource: url: jdbc:mysql://localhost:3306/hr_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: your_passwordserverTimezoneAsia/Shanghai这个参数在MySQL8.0里尤其重要不加的话插入时间字段会报无法识别服务器时区的错误这是新手最容易踩的坑。前后端联调之前后端先启动前端的API请求地址要配置好。Vue项目在vue.config.js里配置代理转发module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端所有请求路径写/api/auth/login请求就会自动转发到后端8080端口完美躲避跨域。5.2 生产环境部署Nginx与jar包并肩作战项目完成开发后生产部署流程我推荐这种方式前端打包成静态文件交给Nginx服务后端打成jar包交给Java进程运行Nginx把/api前缀的请求反向代理到8080端口。前端打包命令是npm run build产物在dist目录下。把dist目录里的文件拷到服务器Nginx的html目录后端用mvn package -DskipTests打出jar包扔到服务器上nohup java -jar hr-system.jar log.txt 21 运行。Nginx的关键配置如下server { listen 80; server_name your_domain_or_ip; # 前端静态资源 location / { root /usr/share/nginx/html/hr_system; index index.html; try_files $uri $uri/ /index.html; # 解决Vue路由刷新404问题 } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html;这行是Vue Router的History模式标配——否则用户在员工管理页按F5刷新Nginx找不到对应的静态文件会返回404。这也是一个高频报错点我见过不少同学部署后页面只能从首页进入就是少了这行。5.3 源码使用与二次开发时要注意的几个坑把项目通读一遍后我发现这类源码最容易出问题的地方集中在三个部分如果你打算基于这套源码二次开发提前避开登录拦截器容易漏配白名单。如果不放行登录接口和静态资源会导致所有人无法登录、前端拿不到验证码图片。源码里在WebMvcConfigurer中配置了interceptor并且用excludePathPatterns排除了/login、/captcha等路径。二次开发时每加一个公开接口记得同步更新白名单。跨域配置只写一半。有些同学生产环境不用Nginx反代直接让前端请求后端完整地址然后又没配CORS就会导致明明接口在浏览器里能访问但Ajax请求就是报跨域。这个问题的根源是浏览器的同源策略跟网络通不通没关系。处理方式要么是开发环境用代理要么后端加cors过滤器。两者选其一不要混着来混着配置反而会出怪问题。数据库SQL文件里的初始密码要记得改。源码自带的管理员密码通常是123456或者admin这种弱口令第一次登录后一定要到用户管理里改掉。我们做过安全测试默认口令是这类内网系统被攻破的头号原因。6. 踩壳实录我在复现和调试这套系统时遇到的三个问题写这篇文章之前我把这套系统完整地从零搭建和调试了一遍中间遇到三个很有代表性的问题拿出来给大家当案例参考你们在部署时如果碰到类似问题可以少走弯路。6.1 Vue项目npm install报错node-sass无法下载现象npm install执行后node-sass相关的安装包下载超时或失败终端全是红色的error日志。排查过程先看报错信息会发现下载路径指向GitHub发布的二进制包。国内环境访问GitHub不稳定这是最常见的原因。我按三步排查先确认node版本是否兼容node-sass对node版本很敏感node 16以下才兼容node-sass 4.xnode 17以上基本必挂再确认是网络问题还是依赖版本问题最后尝试切换到cnpm镜像或yarn安装。解决最稳妥的方式是改用sass实现——安装sass和sass-loader然后在vue.config.js里设置css: { loaderOptions: { sass: { implementation: require(sass) } } }。或者干脆用cnpm镜像走阿里云的源下载速度会快很多。6.2 MyBatis XML里的SQL在启动时报“Invalid bound statement”现象后端启动成功后调用某个Mapper接口的方法立即报错错误信息提到“Invalid bound statement (not found)”。排查过程这类问题的根源是Mapper接口和Mapper XML没有建立映射关系。优先级从高到低检查确认Mapper接口的全限定名和XML文件的namespace一致确认XML文件放在resources/mapper目录下并且Maven打包时没有被过滤掉确认application.yml里配置了mybatis.mapper-locations: classpath:mapper/*.xml检查mapper接口的方法名和XML里的id是否完全一致大小写敏感。解决我最后发现是targe目录下编译产物里根本没有XML文件因为Maven默认只把resources目录下的资源打进去如果XML放在java目录下就会漏掉。把XML移到resources/mapper目录重新编译问题解决。这个坑在真实项目里出现频率极高新手和老手都会踩只是新手不会排查而已。6.3 薪资表的数据精度问题金额用了double还是decimal现象薪资计算后显示的总金额出现类似459.000000001这样的尾差。排查过程这就涉及一个关键选择——金额字段用哪种Java类型。源码里数据库用decimal(10,2)但Java实体类里如果用Double接收经过多次运算就可能出现浮点精度误差。我检查后发现部分接口返回时BigDecimal被序列化成字符串前端再解析成Number又经历了一次精度损耗。解决金额相关的实体字段全部改用BigDecimal避免double的二进制浮点精度问题。前端展示时统一用vue过滤器格式化为两位小数。这个教训适用于所有和钱打交道的系统初期数据类型定了什么后期返工的代价是巨大的。7. 最后的实操建议这套系统的下一步还能怎么扩展如果你准备把这套系统用在真实的公司环境里或者打算以它为基础做毕业设计、项目演示我给你几条实操层面的建议都是这套系统实际投入应用时容易遇到的延伸需求第一员工自助功能一定要补上。现在普通员工登录后只能看公告如果能把申请请假查看工资条维护自己的紧急联系人这些自助功能加进去这套系统才算真正形成了闭环。做这些功能的技术难度不大无非是给employee角色增加对应的菜单权限和数据权限——员工只能操作自己的数据。第二考勤打卡对接。如果公司有钉钉或企业微信不要自己去写硬件对接代码直接找开放平台的官方接口同步打卡记录到考勤表即可。这类对接的核心是处理好时间格式和数据幂等——同一批打卡记录重复同步不能产生重复数据。第三数据备份策略。人事系统里的员工合同、薪资明细、身份证号都属于敏感数据建议数据库每日全量备份保留至少30天。备份用mysqldump一行命令就能加入crontab定时任务成本很低但价值极大。第四报表可视化。当前系统的统计功能可能只停留在简单表格层面。你在掌握了Vue和ECharts之后顺手加几个图表部门人数分布饼图、近半年的入离职趋势折线图、薪资成本漏斗图这个系统在工作汇报中的价值会立刻上一个台阶。最后说句实在话人事管理系统的技术含量并不在于高深算法而在于对业务的理解和对边界情况的处理。把员工信息、考勤、薪资这三滩数据管得清清楚楚让HR告别Excel地狱这套系统的价值就充分体现了。顺着这个思路走下去你会发现所谓管理系统开发核心就是把人在某个业务领域里的工作习惯和规则翻译成系统逻辑的一门手艺。这套源码里已经给了你一个相对标准的翻译范例剩下的事情就是用你的业务理解去充实它了。