说实话在路上看到这套“SpringBootVue人事系统”的资源时我第一反应是又一个“看起来什么都懂、跑起来全是坑”的货。但真正把它的源码结构和部署流程过了一遍之后我认为这套东西在目前的前后端分离实战项目里属于比较稀缺的“能落地、能讲清道理”的参考实现。它不是一个玩具demo而是一套麻雀虽小、五脏俱全的项目骨架非常适合刚啃完框架基础、准备做毕设或入职练手项目的朋友也适合想快速搭一套企业内部后台系统的初级工程师。人事系统这玩意儿功能上无非就是员工管理、部门组织、考勤排班、薪资核算、角色权限这些。但恰恰是这些“看起来不难”的业务最能检验一个开发者对SpringBoot、Vue、MyBatis、MySQL这四样东西的综合把控能力。比如岗位和部门之间怎么设计表关系、权限这块用RBAC还是直接写死、MyBatis的多表关联查询怎么写才不卡死、Vue的路由怎么跟后端接口对齐——每个点拆开都能讲半天。这篇文章我会拿这套系统的源码结构和部署过程当主线把前后端分离项目的完整链路拆开揉碎重点聊几个平时文档里不会写明白的实操细节。1. 项目整体设计与核心需求拆解1.1 人事系统的真实业务边界先聊业务建模。别急着写代码人事系统这种项目第一件事是把数据模型想清楚。你得明确一个问题这套系统到底管哪几件事最常见的人事系统分为三大块组织架构管理部门、岗位、员工档案、考勤与休假排班、打卡、请假审批、薪酬管理薪资结构、社保公积金、月度核算。有些系统还会延伸出招聘管理和培训记录但作为练手级项目或者企业内部轻量系统重点抓前三个就够了。这套源码里实际上也是按照这个边界走的核心表就八张左右部门表、岗位表、员工表、用户表、角色表、权限表或者菜单表、考勤表、薪资表。这个体量非常合适——太少说明业务没讲透太多又会让新手陷入CRUD的泥潭出不来。我见过不少初学者一上来就把表设计成三四十张最后连数据关系自己都理不清。人事系统这种内部管理系统表数量控制在十张以内、关联关系控制在三层以内是维护成本最低的。记住一个原则表设计不是越全越好而是每一张表都能回答一个业务问题。1.2 为什么偏偏是SpringBootVue这套组合前后端分离的方案很多老一点的有人用SpringMVCJSP做单体新潮一点的有人把后端拆成SpringCloud微服务。但对人事系统这种业务场景SpringBootVue就是目前综合成本最低的组合。后端选SpringBoot理由很实在自动配置省掉大量XML配置内嵌Tomcat直接跑jar包和MyBatis集成也足够顺滑。而且在国内的企业环境里SpringBoot的招聘需求和社区生态都是最成熟的遇到问题随便一搜就有答案这对新手来说太重要了。前端选Vue核心原因就两个一是学习曲线平缓JavaScript有点基础就能上手二是有Element UI这套现成的后台组件库表格、表单、弹窗、树形控件全都有能把开发时间压缩一大截。比用React写后台管理界面舒服不少尤其是路由和状态管理这块Vue的官方生态做了很好的封装对于中小型管理系统来说正合适。MyBatis在这套组合里的角色容易被低估。很多人觉得它就是配个Mapper接口写写SQL其实它最大的优势在于让SQL处于完全可控状态。人事系统的查询逻辑经常很复杂——按部门过滤、按入职时间区间过滤、按岗位类型过滤这些用MyBatis的动态SQL写起来比JPA的自动生成SQL要清晰得多也方便DBA做SQL审查。1.3 版本选型直接决定你后面顺不顺这部分的坑我踩过太多。给你的版本搭配建议是这样的JDK不用太激进JDK 8或JDK 11就够SpringBoot 2.x系列跟JDK 8的配合最成熟。SpringBoot建议2.7.x别急着上3.x。SpringBoot 3.x要求JDK 17起步而且一些第三方组件的兼容性还没完全跟上对新手不友好。MyBatis用mybatis-spring-boot-starter版本用2.x对应SpringBoot 2.x的版本。MySQL建议8.0.x注意8.0的认证插件事项后面部署章节我会专门说。Vue用2.x Element UI还是3.x Element Plus如果这套系统你打算自己维护Vue 2的生态资料最多、踩坑方案最全如果打算长期演进直接上Vue 3加Element Plus也没问题。但两个版本之间的API差异不小中途切换很痛苦开工前先想清楚。注意选型最忌“新”字优先。毕设项目也好企业内部工具也好稳才是第一位的。我见过太多人卡在SpringBoot版本过高导致的依赖冲突上一卡就是一整天。2. 后端工程的核心结构与关键代码拆解2.1 后端目录结构约定优于配置一套清晰的后端目录结构本身就能告诉你这个项目怎么扩展。这套源码的后端部分是标准的分层结构src/main/java/com/example/hrms/ ├── controller/ # 控制器层接收请求、返回结果 ├── service/ # 业务层处理核心逻辑、事务边界 ├── mapper/ # MyBatis Mapper接口层 ├── entity/ # 数据库实体类 ├── dto/ # 前端交互的数据传输对象 ├── common/ # 全局结果封装、异常处理、工具类 └── config/ # 安全配置、跨域配置等分层这事看起来简单但很多人分着分着就乱了。核心原则是Controller不写业务逻辑Service不碰HttpServletRequestMapper只做数据访问。我见过某项目在Controller里直接写了一大段数据处理代码后面前端要调整字段结构改得叫一个酸爽。这套系统的结构里有个值得学习的点把DTO和Entity分开。很多新手图省事直接拿Entity回传前端结果把数据库字段都暴露了而且一旦前端需要组合字段就没法处理。DTO层的存在就是给接口的入参出参做一个隔离这是专业项目的标志之一。2.2 权限设计JWT RBAC的经典组合人事系统最关键的模块是权限控制。想象一下普通员工能查看自己的考勤和薪资部门主管能看本部门的数据HR能改所有人的档案——这种分级控制靠什么实现答案就是JWT加RBAC基于角色的访问控制。这套系统的认证流程是用户登录时调用/login接口后端验证用户名密码后签发一个JWT令牌前端把令牌存在localStorage里每次请求在请求头带上Authorization: Bearer token。后端用一个拦截器解析令牌拿到用户ID再根据用户ID查询角色和菜单权限。核心拦截器逻辑大致是public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 某些接口放行比如登录接口 if (request.getRequestURI().contains(/login)) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或登录已过期); } // 解析token把用户信息放入ThreadLocal供后续使用 Claims claims JwtUtil.parseToken(token.substring(7)); UserContext.set(claims); return true; } }你也许要问为什么不用Session因为前后端分离架构下后端接口是无状态的Session存服务端的话每次请求都要查一次缓存而且没法水平扩展。JWT把用户信息编码进令牌本身后端不存状态天然适合这种场景。RBAC这块的落地方案是角色-菜单-权限三张表。用户表关联角色表角色表关联菜单表菜单表里的每个菜单项对应前端的路由路径。前端登录后拿到自己的菜单列表动态生成路由。这个设计很常见但完整跑通的不多尤其是Vue那边的动态路由后面我会专门说。2.3 MyBatis的实战细节动态SQL与多表关联人事系统里最考验SQL水平的是员工列表的查询接口。前端筛选条件可能有姓名模糊搜索、部门下拉选择、入职时间区间、岗位类型。这些条件组合起来会发生变化——用户可能只填了部门也可能同时填了姓名和入职时间这时候怎么办用MyBatis的if标签就能完美解决。select idselectEmployeeList resultTypecom.example.hrms.dto.EmployeeDTO SELECT e.*, d.dept_name, p.position_name FROM employee e LEFT JOIN department d ON e.dept_id d.id LEFT JOIN position p ON e.position_id p.id where if testname ! null and name ! AND e.name LIKE CONCAT(%, #{name}, %) /if if testdeptId ! null AND e.dept_id #{deptId} /if if testbeginDate ! null AND e.entry_date gt; #{beginDate} /if if testendDate ! null AND e.entry_date lt; #{endDate} /if /where ORDER BY e.entry_date DESC /select这个写法有几个细节值得注意where标签会自动处理第一个条件前面的AND避免SQL语法错误时间的边界比较用的是gt;和lt;XML里直接写和会报错分页建议用PageHelper插件能自动生成limit语句但要注意配置合理否则统计总数的SQL会多跑一次。MyBatis的二级缓存也是个容易出问题的地方。默认情况下一级缓存是开启的作用域是同一个SqlSession但在SpringBoot里SqlSession每次请求都会新建所以一级缓存基本等于没开。二级缓存可以跨请求共享数据但如果表数据频繁变动而不做缓存刷新配置会出现数据不一致人事系统这种实时性要求高的场景建议别开二级缓存。2.4 统一返回结果前后端联调的免撕逼神器前后端分离项目最大的沟通成本在于接口约定的不一致。这套系统里的统一返回结构做得比较规矩{ code: 200, message: 操作成功, data: { ... } }后端用泛型封装一个ResultT类所有Controller接口都返回这个结构。前端Axios拦截器统一处理code为200时走成功逻辑code为401时自动跳转登录页code为500时弹错误提示。这能省掉大量联调时的无效沟通。这个设计看似简单但我见过很多项目压根没有统一约定每个接口返回结构都随心所欲。调用方拿到的数据时而有data、时而没有前端每个接口都要特殊处理联调效率极低。如果你要新写一套前后端分离的项目第一件事就是把返回结构约定好这比写业务代码重要得多。3. 前端工程落地与Vue开发要点3.1 Vue工程初始化和目录规划前端部分用Vue CLI初始化工程装好Vue Router、Vuex或Pinia、Axios、Element UI或Element Plus。目录结构建议按模块划分src/ ├── api/ # 按模块分文件的接口请求封装 ├── assets/ # 静态资源 ├── components/ # 通用组件 ├── router/ # 路由配置 ├── store/ # 状态管理 ├── utils/ # 请求工具类、工具函数 └── views/ # 页面组件这里要重点说的是api/目录。每个接口请求都封装成一个函数页面里只负责调用函数不直接写axios请求。比如// api/employee.js import request from /utils/request; export function getEmployeeList(params) { return request({ url: /api/employee/list, method: get, params }); }这个做法的好处是后端一旦调整接口路径前端只需要改一个文件不用满项目搜索请求代码。3.2 动态路由的实现思路前面提到权限控制里后端返回菜单列表前端根据菜单动态生成路由——这个点很多教程不讲但确实是面试高频考点。先别管那么多直接看怎么落地。核心逻辑是登录后调用后端接口获取当前用户的菜单数据菜单项包含路由path、组件路径、图标等字段然后通过Vue Router的addRoutes方法把路由动态注册到路由表中。注意路由需要从静态改成动态以后不能直接写死所有的业务页面路由否则只要知道路径就能访问页面前端权限控制等于零。然后再配一个全局前置守卫判断每次跳转的路径是否在权限路由表里不在就拦截跳404页。// router/index.js 中的关键部分 router.beforeEach((to, from, next) { if (getToken()) { if (!store.state.permission.routes.length) { // 拉取菜单并动态添加路由 store.dispatch(permission/generateRoutes).then(routes { router.addRoutes(routes); next({ ...to, replace: true }); }); } else { next(); } } else { next(/login); } });这里容易踩坑的是页面刷新后Vuex里的菜单数据丢了路由也要重新生成。解决方案是在路由守卫里判断一下store里的路由是否为空为空就重新拉取菜单再走一遍跳转逻辑这样刷新就不会白屏。3.3 表格页面的开发模式人事系统大部分页面都是“表格弹窗表单”的模式。员工列表就是一个典型的例子页面顶部是筛选条件部门选择器、关键字搜索、入职时间范围中间是数据表格分页加载右侧是操作按钮编辑、停用、详情点击新增或编辑弹出抽屉或对话框表单。这套模式在Element Plus里很好实现关键是把代码组织清楚。表格的列定义建议做一个独立的数组统一管理涉及“状态”这类字段要格式化文本加tag标签展示el-table :datatableData el-table-column propname label姓名 / el-table-column label状态 template #default{ row } el-tag :typerow.status 1 ? success : danger {{ row.status 1 ? 在职 : 离职 }} /el-tag /template /el-table-column /el-table分页组件和表格的联动要处理两个状态当前页码和每页条数。每次翻页或修改每页条数都重新调用列表接口。注意切换每页条数时如果当前页码超出了总页数要把页码重置为1不然会出现空数据的情况。3.4 axios封装与Token处理前端请求工具类的封装决定了整个前端项目的代码质量。基础的axios实例需要配置baseURL指向后端服务的地址超时时间放在10秒左右比较合适超时后给用户提示“网络请求超时”别让用户干等着。请求拦截器负责从localStorage取token放进请求头service.interceptors.request.use( config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer token; } return config; }, error Promise.reject(error) );响应拦截器这里是重头戏。除了处理成功状态还要单独处理401状态。401意味着token过期或者无效这时候不能直接弹一个“错误”就完事而是应该清空本地令牌、跳转登录页面、并给出“登录状态已失效请重新登录”的提示。这里有个小坑如果同时发出多个请求多个请求都返回401会重复跳转登录页多次。解决思路是定义一个标志变量在第一个401触发跳转后其他请求不再触发。这些细节看着小但直接影响用户体验。你总不想看到用户在一个页面点了个操作结果连续弹出三次“重新登录”吧。4. 环境准备与前后端本地联调4.1 MySQL安装与初始化别栽在细节上MySQL这块我先聊坑。网上搜“mysql安装教程”的人特别多评论区一片哀嚎基本都在两个问题上一是8.0以上版本的root密码认证方式变了二是安装后发现服务起不来。MySQL 8.0默认的认证插件是caching_sha2_password现在各种客户端工具对它的支持已经越来越好了如果你用的是Navicat 15以上的版本基本没问题老版本就要改认证方式ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;新建一个HRMS数据库然后导入源码里带的SQL初始化脚本。执行脚本前务必用文本编辑器打开看看有些脚本开头会指定数据库名如果跟你的不一致执行会报错。还有MySQL的时区问题非常隐蔽连接串里不加serverTimezoneJava驱动会报“The server time zone value”的错而且就算你没报错存进去的时间也可能差8小时。我的习惯是一律加?serverTimezoneAsia/ShanghaicharacterEncodingutf8。4.2 后端启动从环境变量到第一个接口后端用IDEA打开即可重点看application.yml里的配置server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/hrms?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.hrms.entity有个细节注意driver-class-name在MyBatis配合MySQL 8.0时必须写com.mysql.cj.jdbc.Driver老版本的com.mysql.jdbc.Driver虽然还能用但已经过时了。启动后先访问http://localhost:8080/api/login用POST请求带个测试账号源码里一般都带了admin账号能拿到token说明后端一切正常。这里强烈建议装一个ApiFox或者用Postman来测接口。别在浏览器地址栏里直接访问POST接口浏览器默认发的是GET请求后端路由匹配不到会返回405你还会以为是后端代码写错了。4.3 前端启动与跨域处理用VSCode打开前端工程执行npm install装依赖。这里有个常见的Node版本坑Vue 2项目配合老版本node-sass的时候Node版本高了会导致安装失败报错内容乱七八糟。最稳妥的做法是Node 14-16这个区间。现在很多新手的电脑上装的是Node 18甚至更高这种搭配很容易在node-sass这一步歇菜。装完依赖后npm run serve启动开发服务器默认是8081端口避免跟后端的8080冲突。这时直接访问Vue页面发请求会碰到跨域问题因为前端的地址是localhost:8081后端是localhost:8080浏览器的同源策略会拦下响应。解决开发环境的跨域推荐用Vue CLI的代理配置在vue.config.js里这样写module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };这样前端的请求都走代理浏览器的视角里所有请求都是同源的跨域问题就绕过了。生产环境不依赖这个代理而是用Nginx做反向代理这个下面讲。4.4 联调排障三板斧前后端联调的时候出问题是必然的关键是快速定位问题出在哪一端。我总结了三板斧第一看Network面板。F12打开浏览器控制台切到Network标签看请求是否发出去了。如果状态码是404说明后端接口路径跟前端请求路径对不上如果是500说明后端代码异常——看后端日志去如果请求是红色块状态表明被CORS拦截检查代理配置。第二看后端控制台日志。后端启动时日志级别建议调到DEBUG这样MyBatis会打印出执行的SQL语句。拿到SQL后直接复制到Navicat里手动执行如果手动执行能出结果而接口不行问题就出在参数传递或者Mapper映射上。第三打印关键参数。前端调接口之前把params打出来看看后端进入Controller后把接收的参数打出来。两端一对比就能知道是哪边传的数据对不上。提示联调时最耗费时间的往往是“前端说我没传错后端说我收到了空值”。这种问题百分之八十出在字段命名风格上Java后端习惯驼峰命名前端组件绑定的字段名如果风格不一致就会被反序列化成null。遇到这种情况优先检查DTO里的字段名对照。5. 部署上线从本地到服务器的完整链路5.1 服务器环境准备拿到一台新服务器阿里云、腾讯云都行2核4G配置跑这套系统绰绰有余先做基础配置。装JDK和MySQL我就不重复讲了重点说一下装完之后的几个安全习惯MySQL不要用默认的3306端口对外暴露改个端口或者干脆用防火墙限制只允许本地访问为项目单独建一个数据库账号不要用root跑业务。JDK装好后检查一下版本java -version如果服务器的JDK版本跟你本地开发版本不一致会导致jar包启动报错。强烈建议两边统一省得后面排查版本兼容性问题。5.2 前端构建npm run build之后的事前端部署比后端简单执行npm run build产物在dist/目录里。但这里面有个非常核心的坑构建时的接口地址问题。开发环境你的baseURL配的是/api通过Vite的proxy转到后端。但生产环境没有这层代理所以要么你把baseURL配成后端服务的完整地址如http://你的服务器IP:8080/api要么用Nginx把/api这个路径转发到后端服务。这两种策略的区别很关键第一种是前后端地址完全分离前端静态资源由Nginx托管后端API直接走8080端口。第二种是让Nginx统一接收所有请求静态资源自己托管API请求反向代理到后端。第二种方式更干净因为从外部看所有访问都是走80端口不用暴露后端端口也避免了跨域问题。所以一般推荐第二种——部署时把baseURL还是保留成/api让Nginx去转。5.3 Nginx配置前后端分离项目的最终形态Nginx配置是整个部署环节的核心很多新手部署前后端分离项目时死在这一步。一个标准的配置长这样server { listen 80; server_name 你的域名或IP; # 前端静态资源 location / { root /www/hrms/dist; index index.html; try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; 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模式用户访问http://你的域名/employee这种路径时后端服务器上根本没有这个文件如果不加try_files配置Nginx会返回404刷新一下页面就白屏。加上这行配置后找不到文件时统一返回index.html由前端路由接管。第二个是proxy_pass后面的代理路径。我见过很多人在location /api/里把proxy_pass写成http://127.0.0.1:8080/后面多一个斜杠这样会导致请求路径变成http://127.0.0.1:8080//employee/list后端直接404。proxy_pass后面带不带URI行为完全不一样不带就是原样转发带了就用替换规则。建议用上面那种不带尾部斜杠的写法逻辑更清晰。5.4 后端Jar包的启动与守护打包用Maven执行package就行产物在target/目录下。启动有很多种方式最常用的nohup java -jar hrms-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod hrms.log 21 nohup和让程序在后台运行输出日志重定向到文件。这样就算你关掉SSH窗口服务也不会停。检查服务是否正常tail -f hrms.log curl http://127.0.0.1:8080/api/login还有一点务必注意服务器上用root跑Java服务没问题但数据库连接串里的密码千万别写死在配置文件里提交到公共仓库。如果这是给别人看的学习项目倒还好但如果是生产级别的系统建议用环境变量或配置中心来做密码管理。6. 常见问题与排查技巧实录最后分享几个这套系统在开发和部署阶段最容易踩到的典型问题都是我在实际过程中遇到过的写出来帮你少走弯路。6.1 前后端联调时如何快速定位问题现象前端页面点击查询表格没数据也不报错。排查思路关键看Network面板里的响应体。如果响应体是{code:500,message:...错误信息}那是后端异常。把后端日志打开找到对应的堆栈信息定位代码。如果响应体是{code:200,data:[]}那是SQL查询没查到数据把后端日志里的SQL拿出来手动执行一遍看看是不是条件写错了。如果响应体是{code:404}那是路径不对前后端接口约定不一致。6.2 后端servlet接口偶发性报Connection异常现象系统运行一段时间后偶发报错信息类似Communications link failure。原因MySQL默认的wait_timeout是8小时如果连接池里的连接长时间没被使用MySQL会主动断开。而应用连接池不知道连接已失效下一次获取时就会抛异常。解决方案在数据源配置里加上连接池的检测策略。Druid连接池可以设置spring: datasource: druid: test-while-idle: true validation-query: SELECT 1这个配置会让连接池定时发送心跳测试连接有效性失效连接会被自动剔除。这类间歇性报错最难排查配置好之后基本可以一劳永逸。6.3 部署后图片上传文件无法访问现象本地开发一切正常上传的员工头像在页面显示不出来。原因前后端分离架构下前端通过/api/file/xxx路径访问文件但在生产环境里这个路径被Nginx的location /api/规则拦截了而且反向代理到后端时后端可能又没有处理静态资源的能力。解决方案上传功能建议独立一个文件存储模块。如果坚持本地存储那就把上传的头像放到一个独立的路径比如/uploads/然后在Nginx配置里加一条静态资源路径location /uploads/ { alias /www/hrms/uploads/; }这样文件请求直接由Nginx返回不经过Java应用效率更高。6.4 修改代码后热部署不生效现象改了Java代码后端还是用旧的逻辑运行每次都要手动重启。原因SpringBoot默认不会自动加载磁盘上修改的class文件。IDE里改完代码需要重新编译或者用DevTools依赖。解决方案最简单的是在pom.xml里加上dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId scoperuntime/scope /dependency加了依赖后修改代码并重新编译应用会自动重启。但注意这个依赖不要在生产环境打包时带上去调试完记得去掉或标记为optional。6.5 前端刷新页面后404现象部署到服务器后用户在员工管理页面按F5刷新页面变成404。原因分析Vue Router的history模式下访问/employee路径时浏览器带着这个完整路径向服务器发请求服务器要找到对应的文件或路由回退规则。Nginx配置里没加try_files就会404。解决方案在Nginx的location /块里加上try_files $uri $uri/ /index.html;这行配置的意思就是如果请求的文件不存在就返回index.html然后前端路由接管。实际操作里还有一个更隐蔽的连带问题加了try_files之后刷新是不404了但如果前端的路由是嵌套的比如/employee/detail/1有时候$uri匹配不到资源try_files回退到根index.html没问题但如果你在Nginx里还配置了缓存头要注意避免缓存策略把index.html缓存住导致用户看到的永远是旧版本页面。建议给index.html配上no-cachelocation /index.html { add_header Cache-Control no-cache, no-store, must-revalidate; }而dist里的CSS和JS文件因为内容带hash可以放心缓存。7. 这套人事系统的扩展思路如果你照着这套源码跑通了一遍强烈建议做几个改造练习把学到的东西真正吸收成自己的能力。第一个建议是引入Redis来做验证码存储和Token黑名单。现在系统的Token是无状态的意味着用户退出登录后Token仍然有效这是安全隐患。用Redis存一份Token黑名单或者改为Redis存Session能显著提升系统的安全性。第二个建议是增加操作日志模块。人事系统的数据非常敏感谁改了什么、什么时候改的、从哪里登录的这些审计信息很重要也是拓展简历项目的常见加分项。实现一个OperationLog注解配合AOP切面统一记录业务操作。第三个建议是尝试把员工列表导出为Excel。这个功能在真实的人事系统里基本是标配。用EasyExcel插件设置好表头和数据模型十几行代码就能实现一个导出接口。这三个改造做完你对SpringBootMyBatisVue这套技术栈的理解就不是停留在“能跑”的层面了而是真正进入了“能设计”的阶段。最后再分享一个小技巧遇到任何诡异报错先全文搜一下异常信息的关键字不限定中文直接搜英文原串。Stack Overflow和GitHub Issues上基本都有答案。但注意GitHub上给出的解决方案往往跟你的项目版本不一定一致抄之前先搞清楚人家的运行环境跟你的差在哪不然越改越乱。这套人事系统完整跑通一遍对你的全栈能力提升是非常明显的——从数据库设计到后端接口从Vue组件到Nginx部署整个链路你都亲手趟过一遍以后出去面试聊项目说起话来都有底气得多。