做 Java Web 项目的朋友应该都有同感：框架学完了、视频看完了，手头却缺一个能把整套技术串起来、结构又足够规范的项目。工资信息管理系统恰好是这类项目中非常典型的一个——业务贴近真实场景，技术面上覆盖了后端接口、权限控制、前端页面、数据库设计全链路。这篇文章我就基于一套很标准的工程来拆解：SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0，项目自带完整文档。我会把它的整体设计、核心实现、运行配置和常见坑全部过一遍，边拆边讲为什么这么做。无论你是准备毕业设计、想练手完整的全栈流程，还是需要一套能快速二次开发的模板，这东西都值得你花半小时认真看一遍。
1. 项目概述与技术选型解析
1.1 这套工资管理系统到底在做什么
先说业务范围。一个工资管理系统，核心职责就是管“人”和管“钱”：员工档案、部门归属、考勤数据、工资项目配置、每月工资计算、工资条查询与导出，再加上后台需要的用户登录、角色权限、数据统计。听起来模块不多，但每个模块之间都有数据关联，比如考勤缺勤会扣减工资，部门调整会影响工资核算归属，社保基数变更会改变实发金额。把这些关联理顺，就是一个非常完整的业务系统，也正好覆盖了 Java Web 开发中最常见的 CRUD、关联查询、权限拦截、报表统计等场景。
这套项目用的是经典的前后端分离架构。后端基于 SpringBoot2，提供 RESTful 接口；前端用 Vue3 配合组件库搭页面；数据库用 MySQL8.0；ORM 层用 MyBatis-Plus，把单表 CRUD 的代码量压到最低。项目自带数据库脚本和开发文档，拿到手之后可以顺着文档把环境搭起来，几十分钟内就能在本地跑通。
1.2 为什么是 SpringBoot2 + Vue3 + MyBatis-Plus 这组搭配
选技术栈不能只看“流行”，要看每层解决什么问题。SpringBoot2 到现在依然是生产环境使用率极高的版本，起步快、生态成熟，第三方组件文档齐全，网上遇到问题基本都能搜到解决方案。相比 SSH 时代的 XML 配置堆积，SpringBoot 的自动配置和起步依赖让开发者把精力放到业务本身。
Vue3 的价值主要在 Composition API 和更彻底的响应式机制。写工资管理这类中后台系统，大量页面是表格加表单的组合，Composition API 可以把某个页面的查询逻辑、弹窗逻辑、导出逻辑按功能抽离成独立函数，代码组织比 Options API 清晰很多，团队协作时也不容易互相覆盖状态。
MyBatis-Plus 解决的是 MyBatis 单表操作太啰嗦的问题。它内置了 BaseMapper 和 LambdaQueryWrapper，像“按部门查员工”“按月查工资记录”这种最频繁的查询，不需要手写 SQL 和 ResultMap，条件构造器还避免了拼接字符串带来的错误。真正的复杂 SQL，比如多表关联汇总，依然可以用注解或 XML 手写，两条路都能走，这是我推荐它的核心理由。
MySQL8.0 相比 5.7 的进步主要体现在窗口函数、CTE、更完善的 JSON 支持上。工资系统里的“部门月度工资汇总”“年度成本对比”这类统计，用窗口函数写比临时表拼接简洁得多。默认字符集 utf8mb4 也省去了中文和生僻字乱码的麻烦，新项目没有理由不用 8.0。
2. 功能模块拆解与数据库设计
2.1 核心功能模块梳理
从使用者角度出发，系统可以拆成三个角色视角：普通员工、人事/财务管理员、系统管理员。
普通员工能看到自己的工资条、以往的工资记录、个人资料，不能看别人的数据。人事/财务管理员负责维护员工档案、部门信息、录入考勤数据、配置工资项目、执行月度工资计算，同时具备工资数据导出权限。系统管理员则在上述基础上，还要管理后台用户、分配角色、查看操作日志。
在代码层面，这些角色权限不需要在业务逻辑里到处写 if else。项目里是用 Spring Security 或者拦截器加注解的方式，在 Controller 的方法上声明所需权限，前端再配合路由守卫做菜单和按钮级别的控制。这个设计在工资系统里尤其重要，因为工资数据属于高敏感信息，权限隔离没做好，整个系统的价值就大打折扣。
2.2 数据库表设计与关键字段
我拆过的项目里，这套系统的表结构设计是比较典型的，我建议你拿到脚本后重点看这几张表：
员工表承载基础信息，包括工号、姓名、性别、部门 ID、岗位、入职时间、离职时间、工资卡号。需要注意工号必须有唯一索引，因为很多地方的工资关联都通过工号而不是主键 ID 进行，防止删除重建员工后历史工资串号。
工资配置表用来定义工资组成项，比如基础工资、岗位工资、绩效、餐补、全勤奖，每一项都有类型标识——是基本工资还是补贴还是扣款项。设计成配置表而不是直接建一列“基础工资”字段，是为了让不同岗位可以有完全不同的工资结构。用一个 type 字段区分加项和减项，计算时分别累加。
工资记录表按月存储每个员工的核算结果，包含应发工资、社保公积金、个税、实发工资、工资周期等。这张表的粒度是“员工 × 月份”，所以联合唯一索引建议设置为工号加工资月份，避免同一个人同一个月被重复计算覆盖。
设计这个表结构时有个原则：工资公式里的可变参数，比如社保基数、个税起征点、税率等级，要么放配置表，要么在计算时刻生成快照记录。如果直接在工资记录表里存公式引用，后续政策调整会导致历史数据无法追溯。
2.3 工资计算逻辑是怎么落地的
工资计算是这系统最核心的地方，但它并不神秘，本质就是一条业务规则链：应发工资 = 基本工资 + 补贴项 - 扣款项；实发工资 = 应发工资 - 社保个人部分 - 公积金个人部分 - 个税。
个税部分如果按常见月薪场景，税率是分档累进的，代码里要写一个根据应纳税所得额匹配税率和速算扣除数的函数。很多初级开发者会把税率写死在计算逻辑里，我不建议这么做——正确做法是维护一张税率配置表或配置类，包含级距上下限、税率、速算扣除数。代码里只做区间匹配，配置变了改配置就行。
另一个容易忽略的是发放状态。工资计算和工资发放是两个步骤：计算生成草稿记录，财务复核后确认发放。所以工资记录表里应该有一个 status 字段，取值是草稿、已确认、已发放。这个状态机看似简单，但实际上能避免很多尴尬场景——比如发完工资后误改了数据，所有员工看到一条错误的工资条。
3. 关键实现：从后端到前端的完整落地
3.1 后端分层与接口设计
项目的后端代码我建议按 Controller-Service-Mapper 三层来理解。Controller 层只做参数接收和响应封装，不写业务逻辑；Service 层处理业务规则，比如工资计算、权限校验、事务控制；Mapper 层通过 MyBatis-Plus 的 BaseMapper 继承获得单表 CRUD，复杂统计用自定义 SQL。
前后端接口的规范也很重要。项目里一般会封装一个统一响应体，包含 code、message、data 三个字段。所有的接口成功返回 code=200，业务失败返回自定义错误码，未登录返回 401，无权限返回 403。这样前端 axios 拦截器里只需要判断一次 code，就能统一处理错误提示和跳转登录页。
写这个项目的时候我强烈建议加上全局异常处理。用 @RestControllerAdvice 统一捕获业务异常、参数校验异常和未知异常，把堆栈详情记录到日志，返回给前端的是友好提示而不是一坨堆栈信息。这个能力不难实现，但对系统的健壮性提升巨大。否则实战部署后用户看到 500 页面，排查问题也很痛苦。
3.2 MyBatis-Plus 实际使用中的几个要点
第一，注意分页。MyBatis-Plus 的分页查询需要配置分页插件，不配置的话分页方法只会查出所有数据，内存里伪装成“分页”，数据量一大就出问题。配置方式是在配置类里注册 MybatisPlusInterceptor 并添加 PaginationInnerInterceptor，数据库类型要指定为 mysql。
第二，条件构造器的使用。LambdaQueryWrapper 比普通 QueryWrapper 好在类型安全，字段名写错了编译期就会发现。比如“查部门 ID 为 1 尚未离职的员工”，代码可以写成这样：
List<Employee> employees = employeeMapper.selectList( new LambdaQueryWrapper<Employee>() .eq(Employee::getDeptId, 1L) .isNull(Employee::getLeaveTime) );第三，逻辑删除。员工离职不一定物理删除，用逻辑删除字段更安全。MyBatis-Plus 支持 @TableLogic 注解，标注后所有查询自动追加 deleted = 0 条件。但是要注意，物理删除和逻辑删除混用时，唯一索引会出问题，所以工号这种字段建议干脆不做逻辑删除，离职就置状态，保留完整历史。
第四，自动填充。create_time、update_time 这类字段可以用 MetaObjectHandler 自动填充，不用每次手工 set。我在项目里就是这么干的，既省代码又不会漏字段。
3.3 Vue3 前端页面的搭建思路
前端部分，项目一般会使用 Vite 作为构建工具，配 Vue Router 做路由，Pinia 做状态管理，组件库常用 Element-Plus。Vite 的启动速度和热更新体验比 Webpack 时代好太多，组件按需加载后首屏体积也小很多。
页面结构上，登录页是独立的，登录成功后进入主布局，左侧菜单按权限动态渲染，右侧是内容区。工资管理相关的核心页面有四类：员工管理页（表格加新增编辑弹窗）、工资配置页（可编辑的工资项列表）、月度工资计算页（选择月份触发计算并预览结果）、工资查询页（支持按员工、月份筛选和导出）。
写这种中后台页面时有个经验：把 axios 请求统一封装成一个模块，基础 URL、超时时间、token 携带、响应拦截器都在里面处理好。页面组件里只调用对应的方法，不要每个页面各自 new 一个 axios 实例，不然 token 过期和报错处理就是灾难。
路由守卫的部分也值得提一下。Vue3 的 Router 可以配置全局前置守卫，每次跳转前检查 token 是否存在、当前用户是否有目标路由的权限。没登录的跳登录页，没权限的跳 403，这个逻辑放前端只是体验层面的控制，真正防越权必须靠后端接口权限校验。
3.4 前后端联调与认证授权
联调阶段最常涉及的是接口地址和 Token 传递。后端一般返回 JWT 格式的 Token，前端登录成功后存到 localStorage 或 Pinia 中，之后每次请求在 axios 拦截器里往请求头加 Authorization 字段。
这里有个细节很多人第一次做会踩坑：JWT 默认存在 localStorage 里，刷新页面后虽然 token 还在，但用户信息可能丢了。所以登录成功后要把用户基础信息一并存到 Pinia，并且用 Pinia 持久化插件或者手动在 localStorage 里缓存一份，路由守卫判断用户是否存在。
后端配合认证，常见做法是 Spring Security 加 JWT 过滤器链，或者用轻量级的 HandlerInterceptor 实现。工资管理系统如果没有复杂的 OAuth2 需求，用拦截器处理登录校验，配合注解做角色判断，完全够用，而且比全套 Spring Security 的配置好理解得多。
4. 排坑实录：我踩过的几个坑
4.1 MySQL8.0 连接配置的坑
这个坑基本每个用 8.0 的人都会遇到。驱动类名从 com.mysql.jdbc.Driver 变成了 com.mysql.cj.jdbc.Driver，连接串里需要显式加上 serverTimezone。不配置时区会直接报错，或者时间数据差 8 个小时。如果服务器和数据库在不同时区，建议统一设置为 Asia/Shanghai。
另一个细节是 MySQL8.0 默认使用 caching_sha2_password 认证插件，而某些老版本的连接池驱动不兼容，会导致连接报错。解决办法要么升级驱动到 8.0 对应版本，要么在创建数据库用户时指定 mysql_native_password。经验上直接升级驱动最省事。
4.2 MyBatis-Plus 分页不生效
我见过太多次了：前端表格显示总条数只有一页，查数据库实际有几十条。原因就是没注册分页插件。记住一点，MyBatis-Plus 的分页功能不是自带的，必须要在配置类里添加 MybatisPlusInterceptor。另外，分页插件的顺序如果有多个拦截器，要注意插件顺序，MyBatis-Plus 官网专门提到过拦截器的执行顺序问题。
还有一坑是关联查询分页。如果分页主表是员工，但要关联部门表显示部门名称，写自定义 SQL 时容易把一对多关联的行数带偏。Hermann 这类需求建议先分页查出员工主键，再用 in 查询补充分页结果，或者直接写嵌套子查询保证分页行数正确。
4.3 跨域和 Token 携带问题
前后端分离开发时，前端地址是 localhost:5173，后端是 localhost:8080，浏览器默认会拦截跨域请求。后端加跨域配置是必须的，常见做法是搞一个 WebMvcConfigurer 的配置类，重写 addCorsMappings 方法，指定允许的域名和请求头。
但要注意，允许跨域时 allowedHeaders 必须包含 Authorization，否则前端带 token 的请求会被预检拦截。还有如果是携带 Cookie 的场景，需要设置 allowCredentials 为 true，同时 allowedOrigins 不能使用通配符*，必须写明确域名。这个约束让很多人排查了半天。
4.4 金额精度问题
工资和钱相关的字段，千万别用 float 或 double。MySQL 里用 DECIMAL(10,2) 这样的小数类型，Java 里对应 BigDecimal。计算应发工资时，所有参与运算的值都转成 BigDecimal，用 add、subtract、multiply 做运算，除法时指定精度和舍入模式。用 double 做工资计算，可能在累加时出现 0.1 + 0.2 = 0.30000000000000004 这类问题，放到金额上就是严重的 bug。
前端展示金额时也要注意，JavaScript 的浮点数同样存在精度问题。后端返回给前端的是字符串格式的金额，避免前端拿数字做加减。如果要展示汇总金额，应当由后端计算好返回，而不是前端累加多项数值。
5. 运行部署与二次开发建议
5.1 本地把项目跑起来需要几步
拿到项目之后，先看文档里的数据库脚本。用 MySQL8.0 创建数据库，执行 SQL 脚本导入表结构和初始数据，然后修改后端配置文件里的数据库连接信息。
后端启动前检查一下 JDK 版本。SpringBoot2 对 JDK8 的支持最稳妥，如果你本机装的是 JDK17，部分低版本依赖可能编译报错，建议先用 JDK8 或者把 SpringBoot 版本升级到 2.7 以上。
前端部分安装依赖后有几个常踩问题：npm install 网络慢、依赖版本冲突、Node 版本过高导致 Vite 启动失败。Node 建议使用 Long Term Support 版本，如果安装失败先清缓存，或者换成国内镜像源。启动前端后，页面通过 Vite 的代理把 /api 请求转发到后端端口，这样前端代码里不需要写完整接口地址。
5.2 部署到服务器时的注意事项
本地跑通只是第一步，真正部署才是考验。服务器上部署 SpringBoot 项目，最简单的做法是 Maven 打包成 jar，然后用 java -jar 后台运行。注意服务器的 MySQL 版本和数据库编码，如果服务器 PHP Study 里带的是 5.7，连接驱动和 SQL 语法兼容都要检查，建议服务器也部署 8.0。
前端的部署相对简单，npm run build 生成 dist 目录，把静态文件放到 Nginx 的 html 目录，配置反向代理把 /api 转发到后端端口，再设置 history 模式路由的 try_files 回退。没有配 try_files 的话，刷新页面会 404，这个细节容易漏。
还有生产环境的账号安全。项目自带初始密码，部署前一定要改掉，数据库也不要用 root 直连业务库，单独建一个权限受限的账号更稳妥。
5.3 二次开发可以从哪里入手
如果你不是拿它交作业就完事，建议从三个方向入手扩展。第一个是工资条导出加批量打包下载，现在市面的项目一般只有单条导出或列表导出，支持按部门月度批量生成 PDF 或 Excel 压缩包会更加实用。第二个是审批流程，工资调整、加班申请等设计成简单的审批流，技术上也很有聊头。第三个是统计分析，按部门、按年做工资趋势报表，图表组件配好后端写几条聚合 SQL，功能维度一下子就立体了。
有一点我特别建议：拿到源码后先别急着改功能，先花时间把文档里的数据库设计说明看一遍，搞清楚每张表的用途和关联关系。我见过很多同学上来就改代码，结果把工资计算逻辑改得和表结构对不上，后面查问题查到怀疑人生。把基础吃透，后面的扩展其实都是水到渠成的事。
这套项目作为练手或者二次开发底子，性价比非常高。技术栈主流、代码分层清晰、文档齐全，只要你自己动手把环境搭起来跑一遍，再对着关键代码读一遍，对整个 Java Web 全栈开发的认知都会更上一层楼。
