做毕设选题咨询这几年，被问到最多的问题之一就是：老师，我Java方向，想做个管理系统，选什么题好？我的回答里，薪资管理系统一直排在前三。原因很简单——这个题目看起来普通，但做起来有讲究，既不会让你卡死在技术上，又有足够的空间展示你的水平，应付答辩也稳。
今天顺着“Spring Boot薪资管理系统”这个题，把整个设计和开发的思路从头到尾捋一遍。不管你是刚拿到题还在纠结怎么做，还是代码写到一半发现跑不通，这篇文章应该都能给你一些实打实的参考。我会把模块拆解、表结构、核心代码、踩坑记录、答辩准备全串起来讲，说人话，不讲虚的。
1. 毕设选题拆解：薪资管理系统到底在做什么
1.1 先看清核心业务，别上来就写代码
很多同学拿到“薪资管理系统”这个题，第一反应就是：不就是算工资发工资吗？然后打开IDEA就开始建项目，结果做了一周发现需求越做越乱，代码越写越歪。
这个题目的业务主体其实可以清晰拆成四块：员工信息管理、考勤与薪酬核算、薪资记录与发放、系统权限控制。翻译成人话就是：系统里得有一批员工档案，能记录每个人每个月上了多少天班、请了多少天假，然后根据一套算法算出这个月该发多少钱，最后生成工资条、能查能导出。权限解决的是“谁能看到谁的工资”，这是薪资系统区别于普通CRUD的天然亮点。
再往细了看，员工管理包括部门、岗位、入职时间、薪资标准（基本工资、岗位工资、绩效基数）；考勤部分一般不会让你真的去对接打卡机，更多是从其他系统导入或手动维护每月出勤数据；核算部分是核心，涉及应发工资、五险一金、个税、实发工资的运算；记录部分是每个月生成一条发薪记录，支持条件查询、按月汇总、报表导出。
把这些业务边界划清楚了，你的数据库表和代码结构就有了骨架。凡是毕设做到一半推倒重来的，十有八九是前期没把业务模块理清，做成了“需求驱动开发”——今天想加个功能就加个表，明天觉得缺个字段就改一列，最后整个项目无法收场。
1.2 为什么这个题目适合做毕设：边界清晰，亮点好找
我见过太多人选题选成“智能校园购物平台”“基于大数据的图书推荐系统”，名字听起来唬人，结果工作量全堆在注册登录上，核心业务根本做不透。
薪资管理系统恰恰相反，它的业务边界非常明确，不会让你陷入无休止的需求膨胀。同时它有三点优势值得你答辩时重点讲：
第一，业务有计算逻辑。薪资核算不是纯增删改查，它包含规则运算——不同岗位薪资标准不同、请事假扣款按天算、超过一定金额还要算个税，这些都能体现你对业务的思考深度。第二，数据敏感度高。工资数据天然要求权限隔离，做权限部分你可以理直气壮地讲“这套系统为什么需要RBAC”。第三，有明确的输出物。每月工资汇总、部门薪资对比、年度人力成本趋势图，这些报表和图表的实现，就是答辩现场最能打的“亮点功能”。
一句话总结：这个题目下限低（一个CRUD也能跑通），上限高（你可以加审批流、加报表分析、加消息通知），非常适合不同水平的同学去发挥。热度高是有道理的，它完美契合了毕设评审最看重的“工作量合理、逻辑完整、有技术深度”三要素。
2. 技术选型与架构设计：每种选择都要能说出理由
2.1 Spring Boot为什么要配MyBatis Plus
现在做Java毕设，Spring Boot基本是默认答案。官网那句“Simplify Spring application development”翻译过来就是“让你少写配置多写业务”，这对毕设周期来说太重要了。但面试官或者评审老师一定会追问：为什么选Spring Boot？你至少得说出三点：内嵌Tomcat免部署、自动装配机制、生态成熟。这些答不上来，框架选得再好也是扣分。
持久层我强烈建议用MyBatis Plus，而不是纯MyBatis或JPA。理由很实在：毕设的时间根本不允许你手写大量的ResultMap和动态SQL，MP的BaseMapper直接帮你把单表CRUD做完了，你只需要关注业务本身。而且MP的分页插件PaginationInnerInterceptor用起来比手写PageHelper方便，代码量小，答辩时也好讲。
这里有个很多人踩过的坑：Spring Boot版本选太高。我见过不少同学图新鲜用了Spring Boot 3.x，结果碰到老的教程代码里全是javax.servlet，而3.x已经用jakarta.servlet替换了，导致Filter、拦截器、MultipartFile的导入全部报错。毕设真不建议无脑追新，用Spring Boot 2.7.x系列最稳——网上资料最多，社区踩坑帖最全，和所有MyBatis Plus、Shiro、EasyExcel的兼容性都经过验证。
2.2 核心表设计：一周跑通和一个月返工的分水岭
表结构决定后续代码是“越写越顺”还是“越写越痛苦”。薪资系统我建议按六张核心表来设计，所有业务都围绕它们展开。
部门表和员工表是一对多关系，员工表里存部门ID。员工表的核心字段包括工号（业务主键，建议用字符串），姓名、岗位、薪资标准ID、入职日期、状态（在职/离职）。这里最容易忽略的是离职日期和状态标记——没有这两个字段，你统计历史数据和做离职停薪功能时会非常尴尬。
薪资标准表是整个核算逻辑的源头。包括基本工资、岗位工资、绩效工资、交通补助、住房补助等。注意这些金额字段一定要用BigDecimal，绝不能用了double，否则后续算工资你会发现 0.1+0.2 不等于 0.3，小数点后面跟着一大串奇异数字，这种工资表交上去，老师现场一跑数据就知道你不严谨。
考勤汇总表存放每个员工每月的出勤概况：出勤天数、请假天数、迟到次数、加班时长。这个表不需要精细到每天，只需要给薪资计算提供扣款和加班的依据即可。薪资记录表是核心业务表，字段包括员工ID、薪资月份、应发工资、扣款合计、个税、实发工资、发放状态、发放时间。把应发和实发分开存，是为了后续汇总和导出时不用临时重算。最后还有用户表，建议至少包含用户名、密码、角色ID、关联员工ID，把登录账号和员工信息关联起来。
设计原则永远是那句老话：能复用就不新建，能冗余就不联查。薪资记录里冗余一个员工姓名和部门名称字段，多花不了多少存储，但报表统计的时候能少写一大段联表SQL，访问速度也快。这个细节写进论文里，叫“合理冗余设计”，是加分项。
2.3 分层架构与目录结构
毕设项目的分层要让老师一眼看懂你学过软件工程。我建议标准五层：controller、service、mapper、entity、common。前端页面或接口放controller，业务逻辑收在service接口和impl里，数据库访问走mapper，实体类独立成包，公共的返回结果封装、异常处理、工具类放common。
像下面这样的目录结构，看起来清爽又专业：
src/main/java/com/example/salary/ ├── controller # 接口层 ├── service # 业务接口 │ └── impl # 业务实现 ├── mapper # MyBatis Plus 的 Mapper 接口 ├── entity # 数据库实体类 ├── dto # 前后端交互的数据对象 └── common ├── Result # 统一返回封装 ├── GlobalExceptionHandler # 全局异常处理 └── JwtUtil # Token 工具类前端的部分，如果选Vue，推荐把项目拆成salary-vue和salary-server两个独立目录。毕设场景下，我更推荐用Vue 2 + Element UI而不是Vue 3 + Element Plus，核心原因是Vue 2的生态贴子最多，遇到问题搜解决方案效率高，等你搞明白了毕设也差不多提交了。不用急着上Vue 3，那不是毕设的重点。
3. 核心功能实操：从零搭到能跑通
3.1 环境准备与项目初始化的具体步骤
先说环境。Java 8 或 11 任选一个，JDK版本别高于Spring Boot 2.7支持的上限，否则可能会有兼容性问题。Maven用3.6以上，IDEA直接用2023或2024的稳定版，macOS和Windows上环境配置略有差异，但核心思路一致：JDK装好配好JAVA_HOME，Maven解压后配好MAVEN_HOME和PATH，再用mvn -v验证安装成功。
创建项目，我建议直接在IDEA里用Spring Initializr，选好Spring Boot版本、web、MySQL驱动、Lombok这几个依赖生成骨架。生成之后pom.xml里加上MyBatis Plus和JWT相关依赖，大致是这样：
<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency>数据库连接配置放在application.yml里，有几项必须注意：时区参数要写成serverTimezone=Asia/Shanghai，否则MySQL 8默认的UTC时区会让你插入的时间相差8小时；SSL连接建议关闭，写上useSSL=false，本地开发没必要。
spring: datasource: url: jdbc:mysql://localhost:3306/salary_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的密码 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这个配置文件里有个小细节：map-underscore-to-camel-case要设为true，这样数据库的emp_name字段就能自动映射到实体类的empName，少写一堆@TableField注解。logic-delete-field是开通MyBatis Plus的逻辑删除功能，工资数据不允许物理删除，只能标记删除，这是审计要求，也是答辩时可以讲的细节。
3.2 登录认证：用JWT比Spring Security更有性价比
薪资系统的数据敏感程度高，权限这块必须做扎实。但毕设不建议上一整套Spring Security + OAuth2，配置起来又重又难讲，答辩现场老师不一定有兴趣听你讲过滤链源码。用拦截器 + JWT做轻量级认证是性价比最高的方案，它足够体现你对“无状态认证”的理解。
思路是这样：用户登录时校验用户名密码，成功后生成一个带角色信息的JWT返回给前端。前端把Token存在localStorage里，每次请求放到Authorization请求头。后端写一个拦截器，拦截非登录接口的请求，校验Token合法性，再把解析出来的用户ID塞到请求上下文里，Controller直接取用。
生成JWT的工具类核心代码大概这个样子：
public String generateToken(String username, String role) { return Jwts.builder() .setSubject(username) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey.getBytes(StandardCharsets.UTF_8)) .compact(); }注意两个坑：一是secretKey不能太短，最好至少32字节，否则jjwt会报错；二是这里用的SignatureAlgorithm.HS256是jjwt 0.11.x的写法，如果用了0.9.x，换包名还要换写法，别混着抄。拦截器里对每个请求先判断路径是否在白名单内（例如/api/login、/api/captcha），不在白名单的都得校验Token。
登录接口本身也有讲究：密码不要明文存，数据库里存BCrypt加密后的密文。注册或初始化用户时，密码用BCryptPasswordEncoder加密，登录时用matches比对。你用这个细节，可以在论文“安全设计”一节里写上一段，老师问起来还能当场讲清楚BCrypt的单向哈希原理，这是个免费送分题。
3.3 薪资核算核心逻辑：BigDecimal与计算公式
实现薪资核算，先定义一个计算公式，对应到代码里是一个可复用方法。简化版公式如下：
应发工资 = 基本工资 + 岗位工资 + 绩效工资 + 加班费 - 请假扣款
实发工资 = 应发工资 - 社保扣款 - 个税
这看起来只是加减乘除，但写代码有讲究：每一步计算都用BigDecimal的add、subtract、multiply方法，除法还要指定精度和舍入模式。例如加班费计算，每小时加班费是基本工资 / 21.75 / 8 * 1.5，21.75是月计薪天数，这里要用divide设置保留2位小数和RoundingMode.HALF_UP。
实际编码时要记住一个原则：薪资标准的增删改和核算逻辑要拆开。薪资标准变动是配置项调整，核算需要每次从标准表拉取最新值。“五险一金”这块，毕设不需要做复杂的分段比例，建议配置化简单处理——在数据库加一个比例配置表，或者在薪酬标准里直接用固定金额。答辩时如果老师问“为什么不做阶梯费率”，你可以说“当前版本采用固定金额方案，后续扩展可以接入国家缴费比例配置”，这体现了你思考过真实业务。
3.4 报表导出与可视化：你的答辩亮点区
如果只想做CRUD，系统也能跑，但答辩大概率低分飘过。真正能让评委眼前一亮的，是报表和可视化——每个月的应发实发汇总、部门薪资占比、年度各月人力成本折线图。这类功能代码量不大，但展示效果最直观。
Excel导出推荐用EasyExcel而不是Apache POI。原因就一个字：省。EasyExcel是阿里开源封装的POI，几十行API就能导出带样式的Excel。Alibaba的依赖在Maven中央仓库直接拉取：
<dependency> <groupId>com.alibaba</groupId> <artifactId>easyexcel</artifactId> <version>3.3.3</version> </dependency>导出的Controller方法写法也很简单，直接用流做响应：
@GetMapping("/export") public void export(@RequestParam String month, HttpServletResponse response) throws IOException { List<SalaryRecordVO> list = salaryService.listByMonth(month); response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setCharacterEncoding("utf-8"); response.setHeader("Content-Disposition", "attachment;filename=salary_" + month + ".xlsx"); EasyExcel.write(response.getOutputStream(), SalaryRecordVO.class) .sheet("薪资明细") .doWrite(list); }然后再配一个图表页：前端用ECharts拉后端/api/salary/statistics接口返回的部门汇总数据，生成柱状图和折线图。这里有个经验：统计数据的SQL尽量在数据库层用GROUP BY完成，不要先查全部记录再在Java层循环累加，否则数据量一大接口会巨慢。写SQL时这样查：
SELECT d.dept_name, SUM(s.real_salary) AS total_salary FROM salary_record s LEFT JOIN employee e ON s.emp_id = e.id LEFT JOIN department d ON e.dept_id = d.id WHERE s.salary_month = #{month} GROUP BY d.dept_name答辩时你就拿着这张部门薪资占比图说：这条SQL用了三表关联加GROUP BY聚合，统计逻辑下推到数据库，前端渲染观看效果好。老师一看：该项目是有实际工程味道的。
3.5 考勤数据与工资联动：处理“发薪前”的业务流
没有考勤数据，薪资计算就是无源之水。毕设场景下考勤数据可以做成按月批量导入，前端提供一个Excel模板，用户下载后填写出勤天数、请假天数、加班时长，再上传，后端解析模板批量写入考勤汇总表。这样比手工一条条录入效率高一个量级。
用EasyExcel做一个监听器来处理导入，核心是在invoke方法里逐行读取并校验：
public class AttendanceExcelListener extends AnalysisEventListener<AttendanceExcelDTO> { @Override public void invoke(AttendanceExcelDTO data, AnalysisContext context) { if (StringUtils.isBlank(data.getEmpNo())) { return; // 跳过空行 } // 按工号查找员工，计算该月的出勤汇总并入库 } }把细碎的数据导入做成批量活之后，工资核算的入口就简单了：用户选一个月，系统遍历该月所有考勤记录，逐条调用核算方法，生成薪资记录。这一步务必放在Service层加@Transactional事务注解——因为核算过程需要先删除该月可能存在的旧工资记录，再批量插入新记录，如果中途失败没有事务回滚，数据库就会出现脏数据。为了性能，批量插入用MyBatis Plus的saveBatch，它对List内部做了分批提交，比循环save快得多。
4. 常见问题与排查技巧实录
4.1 开发期最高频的四个报错与解决办法
第一个坑：Spring Boot版本太高，javax全报错。前文就提醒过，Spring Boot 3.x把javax.servlet改成了jakarta.servlet，老代码里HttpServletRequest、MultipartFile全是红色报错。解决办法很简单：降级到2.7.x，或把导入的包统一改成jakarta.servlet。但网上多数教程还是老的javax写法，所以直接降级最省事。
第二个坑：MyBatis Plus分页不生效。很多人加了分页插件依赖后，selectPage返回的数据还是全量。原因是忘了配置分页拦截器。MyBatis Plus 3.5.x必须在配置类里手动注入：
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }不配这个Bean，分页参数会被忽略，查出的永远是整张表，页面假死。这属于MP版升级后的新要求，老帖子不一定提到。
第三个坑：前端传JSON到后端，日期格式死活解析不了。解决起来最简单但最容易忘：在实体类的日期字段上统一加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")，同时保证jackson序列化的配置和前端传参格式一致。别一边用时间戳，一边用字符串，两边不匹配就是400。
第四个坑：跨域问题。前端是localhost:8081，后端是localhost:8080，接口调不通，控制台报CORS。在后端加一个全局CORS配置文件，或者用一个@CrossOrigin注解解决。CORS是浏览器同源策略导致的，服务器端明确告诉浏览器“允许来自该源的请求”即可。这个知识点小而精，答辩时老师问起来也算一个可讲的细节。
4.2 答辩前必须想清楚的技术追问
毕设答辩的提问环节，老师多半不会让你背概念，而是顺着你的代码和表结构追问。薪资系统的高频追问我列在下面，提前准备好，现场不慌：
为什么动态字段要用Double而不是double？因为Entity层需要区分“值为0”和“值为空”。double是基本类型，数据库NULL映射过来直接变0，导致你无法判断这个字段到底有没有工资数据。Spring Boot里凡是对应数据库可空字段的属性，一律用包装类型，这是Java开发的基本素养。
为什么薪资记录要冗余员工姓名和部门名？答：报表统计和列表展示需要高频联表查询，冗余两个字段可以把多表查询降级为单表查询，以空间换时间。这种设计思路叫“反范式设计”，是数据库优化的常用手段。
薪资数据的并发问题怎么处理？如果多个用户同时操作薪资核算，可能产生相同月份数据被覆盖或重复插入。处理方案是：在salary_record表上对(emp_id, salary_month)建唯一索引，插入前先查重，或者直接利用数据库唯一约束，让重复插入直接抛异常，再由全局异常处理器转成提示信息。
项目里JWT是存在哪里的？存在前端localStorage。因此存在XSS风险，所以代码里要注意对前端输入做转义和长度校验。能在答辩时主动说一句“我知道这个方案的局限，比如 XSS 风险”，比讲一大堆优点更让评委认可——这体现了你的安全和系统性思考。
4.3 写论文时值得整合的三个要点
论文结构和项目一样重要。基于这个题，我建议论文里的核心章节至少覆盖下面三条线索：一是需求分析部分画清楚用例图，明确普通员工、部门主管、管理员三种角色的权限差异；二是数据库设计部分把E-R图、数据字典写详细，哪怕是简化版，也要体现外键关系；三是系统测试部分不要只写“测试如下所示”就完事，要记录完整的测试用例表，包含测试输入、预期结果、实际结果，用黑盒用例覆盖登录失败、无权限访问、薪资边界值等场景。
尤其测试设计里，可以有意写两个“算错的场景”：比如当月有请假扣款时核算结果正确、薪资标准为空时系统会默认按0计算并给出提示。这些一旦在台上演示出来，就是“异常处理能力强”的活证据。
5. 技术扩展与进阶思考：让项目从合格变优秀
5.1 加进去会大幅加分但工作量可控的三个功能
核心系统跑通只是70分，想让评分往90分走，建议加三个轻量扩展。
第一个是发送工资条通知。工资发放后，系统调用阿里云短信或邮件接口，把薪资确认提醒发给员工。如果你不想申请短信签名，也可以简化成邮件通知。实现方式是在薪资记录生成后异步调用发送方法，核心代码就十几行。这个功能的价值在于它引入了“异步处理”和“第三方接口对接”两个概念，论文里能写出一小节“系统集成设计”。
第二个是操作日志记录。用AOP切面统一拦截Controller的操作，把谁在什么时间操作了什么功能写入日志表。AOP是Spring框架面试必问，项目里有真实应用场景，你不用背面试题，直接在答辩现场演示你项目里的切面类，说服力比背定义强一百倍。
第三个是可视化大屏。做一个只读的仪表盘页面，展示员工总数、本月应发工资总额、各部门人力成本占比、近半年薪资趋势。整个页面用ECharts实现，后端提供一个聚合统计接口。技术上不复杂，但展示效果瞬间拔高项目档次。做出来的成果截图放论文里，视觉效果会非常突出。
5.2 对一个热点词的回应：Spring Boot整合Flink有必要吗
看了最近很多热词，有同学问“Spring Boot整合Flink做薪资系统行不行”。我的建议很明确：从毕设的角度，不要碰这类方向。Flink是流式计算引擎，用于大规模实时数据处理。一个教学型薪资管理系统，日活用户几十人的量级，用Flink属于大炮打蚊子——性能优势体现不出来，还平白让项目复杂度翻倍，答辩时如果说不清楚为什么引入，反而成了减分项。
如果你的项目确实需要展示实时计算能力，也建议优先选一个更贴合的轻量方案，比如消息队列处理发薪后的通知推送，或者用定时任务做月度自动汇总。技术选型讲究匹配，不是为了炫技而引入新框架。把一个框架用到恰到好处，才是评审老师真正想看到的工程判断力。
5.3 个人操作感受：一次完整跑通项目的节奏感
最后分享一点实际操作时的节奏安排。我建议把这套毕设项目按四周来推进，别想一晚上赶出来。第一周做需求分析和数据库设计，画出用例图和E-R图，把表建好，这是最不能省的一步；第二周跑通用户登录、员工管理和部门管理的增删改查，把基础架子立住；第三周做考勤导入和薪资核算，这是核心业务，也是最容易出问题的一环，要留好调试时间；第四周做报表导出、图表统计，再整体测试梳理边界情况，同时开始写论文框架，项目和文档同步走。
这个节奏把最难的业务逻辑放在了周末，给自己留了充足的缓冲。我见过太多人把项目全堆到最后一周，结果连续通宵三天，接口跑不通，论文一个字没写，最后只能委托代写草草交差。真的没必要这样逼自己，按节奏执行，这套系统每周你都能看到自己的进度，越写越有信心，反而最后轻松过关。
做毕设这事，说到底是一场“有限时间内的工程实践”。不用追求完美，但求每个模块你都能讲清楚设计原因和实现细节，能独立复现核心流程。你在薪资系统里沉淀下来的这套“业务分析 → 表结构设计 → 功能实现 → 痛点优化”的完整链路，远比系统本身更值钱。这套思路换到任何管理系统题目上都通用，以后你工作里接到类似的开发需求，也能直接套用。
