简介这是一套面向Java与前端初学者、实习开发者及中小型项目实践者的人事管理系统完整源码基于SpringBootVue实现前后端分离架构覆盖员工信息管理、部门维护、岗位配置、考勤统计等核心HR业务场景。资源包共189个文件包含60个Java后端业务与控制器类、23个Vue组件及23个JS逻辑脚本、44个PNG图标与SVG/GIF资源辅以XML配置、YML启动参数及SQL初始化脚本结构清晰、模块职责分明便于理解分层设计与接口联调流程。压缩包体积为6.98MB轻量易导入适合快速部署学习或二次开发。已有546人下载学习配套代码具备完整登录鉴权、RESTful API设计、Element UI界面布局及基础权限控制逻辑可直接运行查看前后端交互细节是掌握企业级全栈开发流程的典型参考案例。 搞人事管理系统这个方向说实话这些年经手过不少类似项目。很多朋友拿来一套基于SpringBootVue开发的前后端分离人事管理系统源码第一反应是想跑起来看看效果但真要往自己业务里套就发现细节问题一个接一个。这套系统我拆过也重构过从数据库设计到权限模型从前端列表到部署上线今天抽时间把整个思路和实现过程完整聊一遍给正在做前后端分离项目实战、或者想拿源码改造自用的小伙伴一个参考。先说结论这套东西选型没问题SpringBoot加Vue的组合在中小型企业内部系统里非常能打源码本身也覆盖了人事管理最核心的闭环。但它不是开箱即用的产品更像一个高质量脚手架。想真正落地你得理解每个模块背后的设计意图把业务状态流转理顺把权限模型搞扎实再把部署那一套走通。下面我按拆解源码的顺序把关键环节逐层讲清楚。1. 人事系统要管的不是人是一整套业务状态流转很多初学者看到人事管理系统这六个字脑子里浮现的就是增删改查加个员工、改个信息、删个记录。真这么想做出来的就是一个电子表格不是系统。人事管理的核心是状态流转一个人从进入公司到离开公司他的状态是不断变化的系统要管的其实是这个变化过程以及伴随这个过程的各类业务数据。1.1 员工生命周期的六个关键节点我习惯把所有业务先拆成一条时间线这样后面设计表结构、写接口、画页面都会变得特别清晰。一个员工从候选到归档大致经过下面这些节点状态节点触发条件关键操作产出数据入职登记通过面试、确认到岗录入基础档案、上传证件员工主数据试用期入职当天开始设置试用期时长、工资标准试用期记录转正试用期结束且考核通过更新员工状态、调整薪资转正记录调岗调薪业务调整或个人申请变更部门、岗位、薪酬异动记录离职主动辞职或公司辞退离职审批、工作交接、工资结算离职记录离职归档离职手续办结封存档案、权限回收归档记录源码里的员工状态字段基本就是按这条线设计的通常是一个整数枚举0试用、1正式、2调岗中、3离职再往后就是归档状态。我在实际重构时更喜欢直接用字符串枚举或者Java枚举类因为数字枚举在排查业务时看数据库根本看不明白还得翻代码。public enum EmployeeStatus { PROBATION(probation, 试用期), FORMAL(formal, 正式), TRANSFERRING(transferring, 调岗中), RESIGNED(resigned, 已离职), ARCHIVED(archived, 已归档); private final String code; private final String description; EmployeeStatus(String code, String description) { this.code code; this.description description; } public String getCode() { return code; } public String getDescription() { return description; } }别小看这个状态字段它是整个系统的中枢神经系统。考勤、薪资、审批、报表全部依赖这个状态做关联查询。你要是把状态设计成简单的字符串存在数据库里后面做统计报表时SQL不知道要写多长。1.2 人事系统的六大功能模块围绕这条生命周期线系统需要拆出六个功能域。这也是源码里Controller命名的主要依据组织架构管理部门树、岗位体系、编制管理员工档案管理基础信息、证件信息、教育经历、工作经历、合同信息、紧急联系人考勤管理排班、打卡记录、请假、加班、补卡审批薪资管理薪资结构、核算规则、工资条、社保公积金合同管理劳动合同签订、续签、解除提醒报表中心人员编制报表、入离职统计、学历结构、年龄分布我看过很多学习者拿到源码就急着跑前端把后端启动起来看了一会儿觉得就这然后关掉。问题就出在只看到了页面没看到模块之间的关联关系。真正值钱的不是某个员工列表页面而是部门、员工、考勤、薪资、合同这五张主表之间的耦合方式。1.3 为什么很多公司弃用SaaS选择自研聊个现实问题。现在市面上一套SaaS人事系统一年几千块到几万不等功能还挺全为什么还要用SpringBoot自己搞一套我给出的答案是人事系统是典型的数据敏感型 流程定制型业务。不同公司的试用期规则不同、薪资结构不同、审批链路不同SaaS产品为了兼容所有客户表单字段和流程编排都做得非常抽象。真用起来就会觉得每个功能都有每个功能都差一点。自研系统的好处是数据结构自己说了算字段自己加流程自己编排还能跟内部其他系统打通。源码项目最大的价值不是省掉买SaaS的钱而是提供了一个可以完全掌控的数据底座。你在这个底座上改业务逻辑改多狠都行。2. 这套技术选型的合理性以及它背后的分工逻辑SpringBoot加Vue在前后端分离项目里已经快成标配了但很多人说不清为什么是这两个。我站在改造项目的角度把分工逻辑说透。2.1 SpringBoot层负责一切不该前端关心的事SpringBoot在这套系统里至少承担了以下五个职责缺一个都不行数据建模与数据访问通过MyBatis-Plus或Spring Data JPA映射数据库表业务规则实现计算薪资、校验考勤、判断合同到期核心逻辑全在后端安全认证与鉴权登录签发Token接口校验权限密码加密存储接口协议编排把业务能力暴露成RESTful接口前端只需要关心数据系统集成能力对接邮件服务、消息通知、文件存储、导出工具你发现没有这套分工的核心逻辑是前端不做任何业务判断。我做项目时反复跟团队强调一个原则前端只翻译用户操作、展示数据结果比如试用期员工能不能调薪这种规则判断绝不能出现在前端代码里。否则前端改一个条件后端接口就被绕过数据一致性完全失控。SpringBoot在Java生态里的好处是自动化配置极其省心。一个spring-boot-starter-web依赖内嵌Tomcatjava -jar跑起来就是完整应用。源码里如果看到pom.xml或者build.gradle你会发现依赖管理非常清晰业务模块按starter拆分这是后期裁员维护成本比较低的关键。2.2 Vue层负责交互体验与状态管理前端部分源码里常见的是Vue 2 Element UI或者Vue 3 Element Plus的组合。Vue的响应式机制在处理表单数据、列表筛选、联动选择这些场景时非常顺手。以员工档案录入为例选择部门后岗位下拉要根据部门联动选择婚育状态后某些字段要显示或隐藏。用Vue的computed属性加watch监听器这些联动逻辑写起来非常清爽export default { computed: { // 根据当前选中的部门过滤岗位列表 filteredPositions() { if (!this.form.deptId) return [] return this.allPositions.filter(item item.deptId this.form.deptId) }, // 是否显示紧急联系人区域 showEmergencyContact() { return this.form.contractType formal } }, watch: { form.deptId(newVal) { // 清空岗位重新选择避免数据不一致 this.form.positionId } } }源码前端的路由设计一般会分成两类一类是登录后根据角色动态生成的路由表管理员和普通HR看到的菜单不同另一类是公共页面比如登录页、404页。动态路由这块是前端最需要吃透的部分它跟后端的权限模型紧密绑定。状态管理方面Vue 3项目用PiniaVue 2项目用Vuex。源码里store模块通常包含三个user模块存当前登录用户信息和Tokenapp模块管理侧边栏、标签页等界面状态permission模块管理路由权限。注意这个permission模块千万不要自己造轮子去后端拉菜单表最好是登录后由后端一次性返回该用户的菜单和按钮权限前端store里直接保存。2.3 开发协作模式的转变前后端分离不只是技术架构更是团队协作方式的变化。后端定好接口文档前端拿Mock数据同步开发两边不用互相等。接口文档这块源码里一般会集成Swagger也就是springfox或者springdoc后端的Controller加了注解之后打开swagger-ui就能在线调试每一个接口。在前后端分离项目实战里我最建议你先定死接口协议再动手写代码。协议里至少要包含三块统一响应结构比如{ code: 0, message: success, data: {} }分页参数规范pageNum、pageSize、total统一命名异常码规范业务异常码要从10001开始定义跟HTTP状态码区分开这套东西开发前不定好联调阶段天天扯皮。3. 数据库设计与后端接口这套系统的功底全在这里人事管理系统最见功力的地方不是前端界面多炫酷而是数据库设计。表字段设计好了接口写起来顺手设计乱了后期加一个查询条件都是噩梦。3.1 核心表结构与它们之间的关系源码里核心表一般是这几张我建议你导入数据库之后先用工具画出它们的关系图再动手改代码数据表核心字段关联关系sys_dept 部门表id, parent_id, dept_name, sort自关联树形结构sys_user 系统用户表id, username, password, employee_id关联员工表emp_employee 员工表id, emp_no, name, dept_id, position, status关联部门表sys_role 角色表id, role_name, role_code与用户多对多sys_menu 菜单权限表id, parent_id, menu_name, perms, path与角色多对多sal_salary 薪资表id, employee_id, base_salary, bonus, deduction关联员工表att_attendance 考勤表id, employee_id, work_date, check_in, check_out关联员工表员工表是绝对核心其他表都用外键或者逻辑关联指向它的主键。这里注意一点我不推荐数据库物理外键全部用逻辑关联理由很简单物理外键在做分库分表或者数据归档时特别痛苦而且删除顺序稍微不对就报外键约束错误。业务系统里外键约束由应用层去保证。员工表字段设计上除了工号、姓名、性别、出生日期这些常规字段有几个字段是最容易被忽略的入职日期和转正日期很多系统只存一个入职日期社保缴纳城市影响社保公积金计算规则银行卡号和开户行发工资要用紧急联系人姓名和电话要允许一个人录多个所以应该拆子表员工照片URL注意本地存储还是对象存储决定后续部署复杂度我见过最头疼的一个客户他们的组织架构有四级集团、公司、事业部、部门。原来的系统只支持两级硬生生往dept表里塞。做人事系统前一定先跟业务确认组织层级最多几层这会影响树形查询的写法。3.2 一个完整的分页查询接口是怎么设计的以员工列表查询为例这个接口几乎是所有管理系统的样板间源码里最值得精读的就是它。我结合一个标准实现说明白RestController RequestMapping(/api/employee) public class EmployeeController { Autowired private EmployeeService employeeService; GetMapping(/page) public ResultPageResultEmployeeVO page(Validated EmployeeQuery query) { return Result.success(employeeService.pageQuery(query)); } }EmployeeQuery继承了分页基类包含了pageNum、pageSize以及姓名、部门ID、状态、入职时间段等查询条件。Service层负责组合这些条件MyBatis-Plus的LambdaQueryWrapper写动态SQL非常方便public PageResultEmployeeVO pageQuery(EmployeeQuery query) { LambdaQueryWrapperEmployee wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(query.getName()), Employee::getName, query.getName()); wrapper.eq(query.getDeptId() ! null, Employee::getDeptId, query.getDeptId()); wrapper.eq(query.getStatus() ! null, Employee::getStatus, query.getStatus()); wrapper.between(query.getStartDate() ! null query.getEndDate() ! null, Employee::getHireDate, query.getStartDate(), query.getEndDate()); wrapper.orderByDesc(Employee::getCreateTime); PageEmployee page new Page(query.getPageNum(), query.getPageSize()); PageEmployee employeePage employeeService.page(page, wrapper); // 转VO将部门ID转化为部门名称 ListEmployeeVO records employeePage.getRecords().stream() .map(employee - { EmployeeVO vo new EmployeeVO(); BeanUtils.copyProperties(employee, vo); vo.setDeptName(deptService.getById(employee.getDeptId()).getDeptName()); return vo; }).collect(Collectors.toList()); return new PageResult(records, employeePage.getTotal()); }这段代码看起来简单里面对前端非常关键的一个设计是返回给前端的对象叫VO不是数据库实体。原因有两点一是数据库字段不一定想全暴露给前端比如员工表里的身份证号、银行卡号这种敏感字段列表接口根本不该返回二是VO可以自由组装前端需要的展示字段比如部门名称、岗位名称让前端少掉一次联查。3.3 入职、转正、离职这几个状态接口的事务控制人事系统里最容易出数据问题的是状态流转接口。假设执行入职操作后端要做的事情包括插入员工主表、插入用户账号、分配初始角色、记录操作日志。这四步任何一个失败前面的操作都不能生效必须在一个事务里。Transactional(rollbackFor Exception.class) public Long createEmployee(EmployeeCreateDTO dto) { // 1. 校验工号唯一性 if (employeeService.count(new LambdaQueryWrapperEmployee() .eq(Employee::getEmpNo, dto.getEmpNo())) 0) { throw new BusinessException(工号已存在); } // 2. 保存员工信息 Employee employee new Employee(); BeanUtils.copyProperties(dto, employee); employee.setStatus(EmployeeStatus.PROBATION.getCode()); employeeService.save(employee); // 3. 创建系统账号 User user new User(); user.setUsername(dto.getEmpNo()); user.setPassword(passwordEncoder.encode(initPassword)); user.setEmployeeId(employee.getId()); userService.save(user); // 4. 分配默认角色 userRoleService.assignDefaultRole(user.getId()); // 5. 写入操作日志 operationLogService.record(入职, 创建员工 dto.getName()); return employee.getId(); }注意Transactional只能保证Spring容器管理的异常回滚如果你在方法内自己catch了异常没有抛出事务就失效了。所以rollbackFor要显式声明而且要保证所有业务异常都继承RuntimeException并抛出。源码里如果有统一的全局异常处理器RestControllerAdvice那么业务代码里只管thrownController层不用try-catch这个设计是非常值得保留的。3.4 时间字段这个坑前后端都得注意Java后端用LocalDateTime前端用JavaScript的Date序列化格式如果不统一查出来的时间是2025-01-15T08:30:00用户看得一脸发懵。源码里一般会配置全局的日期序列化格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8配置GMT8这个细节尤为重要。我排查过不止一次为什么提交的时间比我本地时间早了8小时的bug原因就是服务器部署环境时区是UTC数据库连接串里没有指定时区。MySQL里连接URL建议加上jdbc:mysql://localhost:3306/hrms?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai4. 权限模型与多角色管理源码里最值得借鉴的部分人事系统的用户角色非常典型超级管理员、HR管理员、部门经理、普通员工。四种角色能看的数据、能做的操作完全不同。源码中实现权限的部分说它是整个项目的精华都不为过。4.1 RBAC模型在三张表里的落地这套权限模型叫RBAC角色访问控制具体落地就是五张表的关联关系用户表、角色表、菜单表加上用户角色关联表、角色菜单关联表。它解决的问题是不给用户直接授权而是给角色授权用户挂到某个角色上就继承了该角色的所有权限。好处是权限调整只改角色不用一个个用户去配。部门经理调岗了换一个角色即可他的所有权限跟着变。菜单权限表的perms字段是关键它存储权限标识字符串比如employee:list、employee:export、salary:update后端接口用这个字符串做鉴权。4.2 Spring Security JWT的鉴权流程源码里要是用的Spring Security核心就两个部分认证和授权。认证解决你是谁授权解决你能干什么。登录流程是这样的用户提交用户名密码后端校验通过后签发一个JWT Token这个Token包含了用户基础信息之后前端所有请求都在请求头带Authorization: Bearer token后端拦截器解析Token拿到用户身份和权限集合。关键配置在自定义的SecurityFilterChain里Bean SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests() .antMatchers(/api/auth/login, /api/auth/captcha).permitAll() .antMatchers(/swagger-ui/**, /v3/api-docs/**).permitAll() .antMatchers(/api/employee/**).hasAuthority(employee:list) .antMatchers(/api/salary/**).hasAnyAuthority(salary:view, salary:update) .anyRequest().authenticated() .and() .exceptionHandling() .authenticationEntryPoint(jwtAuthenticationEntryPoint) .accessDeniedHandler(customAccessDeniedHandler); http.addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); }这套接法在前后端分离项目里是标准范式。无状态会话让后端可以水平扩展多实例部署不用考虑Session共享问题。JWT的密钥要放配置文件里用环境变量注入不要硬编码在代码里。4.3 前端路由守卫和按钮级权限后端鉴权做完前端还有一层控制。Vue Router的路由守卫里每次跳转前检查本地有没有Token没有就跳到登录页。router.beforeEach(async (to, from, next) { const token useUserStore().token if (!token) { if (to.path /login) { next() } else { next(/login) } return } // 已登录且要去登录页直接跳首页 if (to.path /login) { next(/) return } next() })按钮级的控制一般用自定义指令v-permission实现。一个导出员工按钮管理员能看到普通HR看不到这就是按钮级权限app.directive(permission, { mounted(el, binding) { const requiredPerms binding.value const userPerms useUserStore().perms if (requiredPerms !userPerms.includes(requiredPerms)) { el.parentNode?.removeChild(el) } } })el-button v-permissionemployee:export clickhandleExport导出/el-button注意一个要点前端隐藏按钮只是提升体验真正的安全防线在后端接口权限。前端可以绕过按钮直接调接口后端必须做好二次校验。这是前后端分离架构最容易踩的认知坑。5. 前端页面的几个关键实现改源码前必看前端页面多但核心套路就几个。摸清这几类页面的实现模式改任何后台管理系统都事半功倍。5.1 员工列表页的分页、搜索、批量操作模式列表页是所有管理系统的门面也是使用频率最高的页面。源码里员工列表页基本遵循同一个模式顶部搜索区姓名、部门、状态的组合条件主表格区分页表格操作列有编辑、离职、分配账号等按钮批量操作栏勾选后批量导出、批量调整部门el-table的分页用法我就不多说了只提醒一个细节表格列的宽度和溢出处理。员工姓名、部门名称这些字段不长固定宽度就好但入职时间这种用YYYY-MM-DD格式的最好用formatter或者插槽自定义展示。5.2 多步骤入职表单的实现入职登记页面我见过各种写法最推荐的是el-steps加多步表单。第一步基础信息第二步教育经历第三步合同信息第四步账号设置每一步校验通过才能进下一步最后提交时一次性调后端接口。实现逻辑上要注意步骤条组件里每个step的内容不要平铺在一个大form里而要拆成子组件这样每步的校验规则互相独立不会出现填了第四步的错把第一步的校验也带出来的体验问题。如果源码里用的是Vue 3 Element Plusel-form的rules校验规则要利用好trigger字段区分blur失焦校验和change值变化校验。比如员工工号唯一的校验应该用加debounce防抖的异步校验用户输入完再发请求过程中加loading提示。5.3 人员报表与数据导出的两种方案人事系统的报表模块我归纳下来就两种实现路径图形化报表用ECharts绘制组织架构图、入离职趋势、学历分布饼图表格化导出前端调后端导出接口后端生成Excel或PDF文件返回给前端下载这里重点聊导出。Excel导出一般用EasyExcel配合自定义样式注解导出的文件可以直接用Excel打开不会乱码。PDF导出在热词里出现频率很高前后端分离下实现步骤通常是后端准备数据、填充PDF模板、返回文件流、前端接收blob后触发下载。// 前端接收文件流的通用处理 download(res) { const blob new Blob([res.data], { type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet }) const url window.URL.createObjectURL(blob) const link document.createElement(a) link.href url link.setAttribute(download, 员工花名册.xlsx) document.body.appendChild(link) link.click() document.body.removeChild(link) window.URL.revokeObjectURL(url) }注意axios请求必须设置responseType: blob否则下载下来的文件打不开。这个坑我遇到不下十次。5.4 统一请求封装前端axios封装是必看的。一套规范的封装至少包含四件事请求拦截器注入Token、响应拦截器解包统一数据、错误码统一提示、401时自动跳登录页。源码里如果这套封装做得好你改造任何模块都会非常顺手。service.interceptors.response.use( (response) { const res response.data if (res.code ! 0) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message || 请求失败)) } return res }, (error) { if (error.response?.status 401) { useUserStore().logout() router.push(/login) } else { ElMessage.error(error.message || 网络异常) } return Promise.reject(error) } )6. 源码跑通到上线部署我实测中踩过的坑和优化建议这一步可能是标题党们最容易忽略的部分。基于SpringBootVue开发的前后端分离人事管理系统源码跑起来容易部署上线才是真正的考验。我把自己实测中遇到的高频问题整理成清单每一条后面都跟着解决办法。6.1 跨域问题的三种解决方式前后端分离后前端跑在8080端口后端跑在8081端口请求跨域浏览器直接拦截。解决办法常用的有三种方式适用场景优点缺点后端CORS配置开发调试配置简单生产环境暴露端口前端proxy代理开发环境最常用无跨域生产环境不生效Nginx反向代理生产环境最规范、性能好需要额外配置开发环境下Vite或者Vue CLI的proxy配置是首选// vite.config.js server: { proxy: { /api: { target: http://localhost:8081, changeOrigin: true } } }生产环境用Nginx配置方式是前端静态文件由Nginx托管/api开头的请求反向代理到后端服务。注意加上proxy_set_header Host和X-Real-IP否则后端打日志拿不到真实客户IP。6.2 后端打包与部署的完整步骤后端的部署实际上不复杂但版本环境和配置文件坑多。假设服务器是Linux CentOS 7操作流程如下服务器安装JDK 8或JDK 17取决于源码的spring-boot版本安装MySQL导入源码里的sql初始化脚本修改MySQL账号密码为安全值把数据库连接信息放入SpringBoot的application.yml代码里用Maven打包mvn clean package -DskipTests把target目录下的jar包上传到服务器启动命令nohup java -jar hrms.jar --spring.profiles.activeprod /opt/hrms/logs/hrms.out 21 这里最容易被忽略的坑是数据库大小写敏感问题。Linux服务器上MySQL默认表名大小写敏感Windows上不敏感。源码里的表名如果是小写下划线风格导入Linux的MySQL没问题但字段名如果用了驼峰就得注意MyBatis-Plus的自动驼峰映射是否正常。配置里加上map-underscore-to-camel-case: true可以省掉一堆麻烦。6.3 前端打包的清单前端打包相对简单但也要注意几个点.env.production文件里的VITE_API_BASE_URL要配置成生产环境的API域名一般写/api由Nginx转发或者写完整域名路由模式如果是history模式Nginx需要配置try_files兜底否则刷新页面就404打包产物dist目录上传到Nginx的html目录下Nginx里history模式的核心配置location / { root /opt/hrms/dist; index index.html; try_files $uri $uri/ /index.html; }6.4 Long类型精度丢失前端ID变成科学计数法这个坑我只说一次但必须说后端主键如果用了雪花算法生成的ID是19位Long类型前端JavaScript的Number类型只能精确表达2^53以内的整数超过后精度丢失表现为ID最后几位变成了0。查详情报404问题就在这里。解决方案是在后端统一对Long类型序列化时转成字符串spring: jackson: generator: write_numbers_as_strings: true或者使用注解在特定字段上转JsonSerialize(using ToStringSerializer.class) private Long id;6.5 项目上线前的安全检查安全这块说几条最基础的都是我在实际项目中遇到的所有用户密码必须BCrypt加密不能明文存储敏感接口比如获取员工身份证信息要做数据权限校验不能只看登录没登录文件上传接口要限制文件类型和大小防止恶意文件上传定时任务要防止重复执行多实例部署时用分布式锁前端和后端日志里不要打印完整身份证号和银行卡号做脱敏处理热词里看到springboot解决pdf xss攻击这类搜索本质就是用户上传的文件或者导出的PDF里包含了恶意脚本处理方式是导出前对内容做转义上传时校验MIME类型和内容嗅探。这套人事源码如果集成了文件上传功能建议把这一块补上。6.6 二次开发优先级到底怎么排最后给正在拿这套源码做二次开发的朋友一个建议顺序先改数据库加自己业务需要的字段同步改实体类和前端表单再改权限把角色菜单配置理顺让每个角色只看到该看的东西然后改流程把入职、离职、调岗这些审批链路跟自己的组织架构对齐最后做报表把统计口径确认好再写查询SQL别上来就改前端样式。前端样式再好看后台逻辑一堆问题上线以后天天被业务部门轰炸。我在实际使用中发现很多人事系统的源码版本差异很大有的用SpringBoot 2.7加Vue 2有的用SpringBoot 3加Vue 3。选型时优先选SpringBoot 3之前用JDK 8的版本生产环境跑起来兼容性最好。如果非要上SpringBoot 3那JDK 17是底线而且很多老一点的MyBatis-Plus版本不兼容注意查一下依赖版本。另外再分享一个小技巧拿到源码后先不要急着运行把接口文档Swagger打开浏览一遍把所有接口的路径、参数过一遍你在脑子里画出了系统的整体地图后面改代码心里就有底了。如果源码里没有集成Swagger花半小时补上这个时间花得绝对值。本文还有配套的精品资源点击获取