Spring Boot人力资源管理系统开发实战：从架构设计到Docker部署

去年我把基于Spring Boot的企业人力资源管理系统从选题一路做到了答辩、部署上线，整个过程下来最大的感受是：这类系统真正难的地方不在编码，而在设计思路是否清晰、技术选型是否能自圆其说、细节能不能经得起追问。这篇文章就把整套东西拆开讲，从架构设计到核心模块实现，从论文写法到坑点排查，一次说透，适合正在做Spring Boot毕设、或者刚入门想搞明白一个完整项目是怎么落地的人参考。

1. 系统定位与整体架构设计

1.1 这套人力资源系统到底解决什么问题

企业人力资源系统，说白了就是把HR日常的重复性工作搬到线上：员工档案维护、部门管理、考勤记录、薪资核算、招聘流程跟踪。很多小公司还在用Excel管理几百号人的信息，一旦入职离职频繁、考勤规则复杂，那就真的是一场灾难。这个项目要解决的痛点就是"信息孤岛"和"数据一致性"——让所有人事数据集中存储、按权限分级查看、流程线上化审批。

我在论文摘要里是这样定位的：本系统面向中小型企业的HR管理场景，采用B/S架构，实现员工信息、考勤、薪资、招聘等核心业务的一体化管理，提升人事管理效率与数据准确性。这个定位非常重要，因为论文答辩时老师必然会问"你和市面上的HR系统有什么不同"，你要提前想好边界——你做的是轻量级、可定制、面向中小企业的版本，而不是跟SAP、用友那些大型套装硬碰硬。

系统最终划分成了七个功能模块：员工档案管理、部门管理、考勤管理、薪资管理、招聘管理、系统公告管理、用户与权限管理。每个模块都遵循同一套增删改查的思路，但业务细节各不相同，这就给论文中的"模块设计与实现"章节提供了充足的写作素材。

1.2 技术选型：为什么是Spring Boot + MyBatis + Vue这套组合

先说我最终选定的技术栈，再解释为什么这么选：

为什么Spring Boot是首选？因为它的自动装配机制把繁琐的配置项压缩到了极限。以前用SSH框架，光配置文件就要写一大堆XML；Spring Boot用约定优于配置的思路，几个依赖加一句@SpringBootApplication，一个可运行的Web项目就起来了。更关键的是它的起步依赖（Starter）体系——引入spring-boot-starter-web就自动带上了内嵌Tomcat，引入spring-boot-starter-data-redis就帮你配好了RedisTemplate，这种能力在学校做毕设的时候省出来的时间是非常可观的。

MyBatis-Plus则是MyBatis的增强插件，内置了通用Mapper和通用Service，单表操作基本不用写SQL。我做员工模块时，分页查询直接调用page()方法，条件构造器用LambdaQueryWrapper动态拼装查询条件，代码量比原生MyBatis少了近一半。但要注意，MyBatis-Plus不是银弹——多表关联复杂查询、统计报表类的SQL，还是老老实实写在XML里更清晰可控。比如说薪资模块要联合员工表、部门表、考勤表做月度汇总，这种SQL我在XML里手写，配合<where>标签动态拼条件，排查问题也方便。

前端选Vue最现实的理由是生态成熟、网上现成组件多。Element UI的管理端组件几乎开箱即用，表格、表单、弹窗、树形控件都有，做后台管理界面效率极高。前后端分离的好处是后端只需要提供JSON接口，前端页面调试独立进行，联调阶段双方可以并行推进。

1.3 前后端分离架构下的请求流转路径

前后端分离的架构下，一个完整的请求是怎样流转的？这是论文里必须讲清楚的核心内容，也是答辩时高频考察点。

前端Vue发起请求后，经过Nginx反向代理转发到后端Spring Boot应用，请求先到达Controller层，Controller负责参数接收和字段校验，然后调用Service层处理业务逻辑，Service层再通过Mapper接口操作数据库。数据返回时反向逐层封装为统一格式的JSON响应，最终渲染到前端页面。

这个分层思想对应着Spring MVC的经典架构：

• Controller层：负责接收请求、参数校验、调用Service、返回响应。只做调度，不写业务逻辑。
• Service层：业务逻辑的核心层，事务管理就在这里控制。方法上添加@Transactional注解完成事务的声明式管理。
• Mapper层：数据访问层，通过MyBatis映射SQL语句和结果集。
• Entity/DTO/VO：数据模型的分层隔离。Entity对应数据库表结构，DTO用于接收前端参数，VO用于返回前端视图数据，三者分离可以避免把数据库字段直接暴露给前端。

这里有个容易犯错的地方：很多初学者图省事直接用Entity接收前端参数，结果多传了几个字段导致数据库批量更新出错，或者返回时把密码哈希也带出去了。我在项目里坚持用DTO和VO做数据隔离，员工新增时用EmployeeDTO接收参数，查询返回时用EmployeeVO脱敏处理，密码字段、内部备注一概不带出。

2. 数据库设计与核心模块拆分

2.1 核心表结构设计思路

数据库设计直接决定了后面开发的顺利程度。我这个项目一共设计了11张表，核心的几张表结构如下：

员工表（employee）

考勤表（attendance）

薪资表（salary）

用户表（sys_user）与角色表（sys_role）：用户表存登录账号密码（BCrypt加密存储），角色表存角色编码。用户-角色中间表做多对多关联。权限模型采用经典的RBAC（基于角色的访问控制）设计——用户拥有角色，角色绑定权限，菜单管理根据权限动态渲染。

设计要点有三条。第一，外键逻辑约束而非物理约束，不在数据库层面强加外键，而是在代码里保证引用完整性，这样后续分库分表、数据迁移时更灵活。第二，所有业务表都带create_by、create_time、update_time字段，做数据追溯非常有用。第三，状态字段用tinyint不用varchar，不管是员工状态还是考勤状态，用数字标识加注释即可，查询效率更高且不容易写错。

2.2 模块拆分与边界控制：该做什么、不该做什么

模块拆分是论文的开篇重头戏，也是项目启动前必须想清楚的问题。我当时在开题报告里做了这样一张模块划分表格：

• 基础数据模块：员工档案、部门管理、职位管理
• 业务流转模块：考勤管理、请假审批、薪资核算
• 招聘辅助模块：职位发布、简历入库、面试安排
• 系统管理模块：用户管理、角色分配、公告发布
• 数据统计模块：人数统计、部门分布、考勤汇总

但这里我必须泼一盆冷水：学校项目，尤其是毕设，模块不是越多越好。我一开始还想做绩效管理、培训管理、社保公积金自动计算，后来发现课程设计和几个月时间根本做不完，强行做只会每个模块都半吊子。最后砍到上面五个模块，把精力集中在员工、考勤、薪资这三个核心链路上，把用户体验和代码质量做好，才是更聪明的策略。

答辩时老师也问过为什么不做绩效模块，我的说法是"项目定位为轻量级HR管理工具，绩效评估的标准因企业而异，强行标准化反而会偏离实际业务需求"，这个回答比硬撑着做完一个简陋的绩效模块要好得多。所以论文选题阶段就要想清楚：哪些是必须做深做透的核心模块，哪些是锦上添花的扩展模块，哪些是答辩时拿来证明"我有扩展思路但未实现"的展望内容。

3. Spring Boot核心技术点的落地实现

3.1 从@SpringBootApplication看自动装配：别再把三种注解混为一谈

Spring Boot最核心的机制就是自动装配，这一块几乎是答辩必问，所以务必真正理解而不是背概念。@SpringBootApplication实际上是一个组合注解，它由三个注解拼起来：

• @SpringBootConfiguration：标志当前类为配置类。
• @EnableAutoConfiguration：开启自动配置，这是自动装配的开关。
• @ComponentScan：扫描当前包及子包下的组件。

真正让Spring Boot智能起来的是@EnableAutoConfiguration。在Spring Boot 2.x里，它通过AutoConfigurationImportSelector加载META-INF/spring.factories文件中声明的自动配置类。比如你引入了spring-boot-starter-web依赖，自动配置类ServletWebServerFactoryAutoConfiguration就会在所有满足条件的情况下生效，帮你创建内嵌Tomcat服务器。

但这个加载过程不是无脑生效的，自动配置类上面通常还有一堆@ConditionalOnClass、@ConditionalOnMissingBean这类条件注解。以Redis自动配置为例：只有classpath下引入了RedisTemplate相关的类，且容器中没有用户自定义的RedisTemplate时，自动配置的RedisTemplate才会生效。这就解释了为什么你在项目里自己定义了一个RedisTemplate后，Spring Boot不会重复帮你创建——自动装配的底层逻辑其实是"条件装配"。

实战扩展：我在系统里要统一Redis序列化方式，默认的JDK序列化方式存到控制台里全是乱码。做法是自定义一个RedisConfig配置类，重新声明RedisTemplate<String, Object>，把Key序列化器改为StringRedisSerializer，把Value序列化器改为Jackson2JsonRedisSerializer。因为自动配置遵循@ConditionalOnMissingBean原则，我的自定义Bean会覆盖默认配置，不需要额外"关闭"任何东西。

这么一通讲下来，自动装配在论文里就不是一个口号，而是一条可以展开论述的技术主线。答辩时老师如果追问"如果第三方组件也想被Spring Boot自动配置怎么办"，你还能说出自定义starter的大致思路——编写AutoConfiguration类、在spring.factories中注册、用@ConditionalOnProperty控制开关。能有这个深度，基本上这块就稳了。

3.2 Controller、Service、Mapper三层的编码规范与事务处理

这块我想重点讲事务，因为太多人栽在事务失效上。系统里给员工办理入职的操作，涉及插入员工表、初始化账号、记录操作日志三个动作，任何一个失败都应该整体回滚。实现方式是在Service方法上添加@Transactional(rollbackFor = Exception.class)注解。

为什么要显式声明rollbackFor = Exception.class？因为Spring默认只在RuntimeException（运行时异常）时回滚，而很多自定义的业务异常是继承自Exception的受检异常，不指定的话事务怎么都不会回滚。这个细节我踩过坑，某次薪资核算批量更新数据库时因为一个空指针异常导致数据只更新了一半，排查了半天才发现是回滚策略没配好。

还有一个高频坑是事务自调用失效。如果你在同一个Service类里写了一个方法A，方法A内部直接调用另一个方法B，B方法上面的@Transactional是不会生效的。原因是Spring事务基于动态代理实现，自调用走的是this引用而不是代理对象，事务拦截器压根没机会介入。解决办法有两种：一是把B方法拆到另一个Service类中注入调用，二是通过AopContext.currentProxy()获取代理对象再调用。

这里顺便说一个跟代理相关的知识点：Spring Boot 2.x默认使用CGLIB代理而非JDK动态代理，因为CGLIB不需要目标类实现接口。这个默认行为带来一个直接影响——如果你在Service里只写实现类不写接口（我习惯这样写），事务、日志等AOP功能依然正常。但如果沿用老的SSH习惯写接口，要小心某些第三方框架对接口代理的强制要求，遇到ClassCastException时首先怀疑代理方式不匹配。

Controller层参数校验我也多说一句，不要全靠手写if判断。在DTO字段上加@NotBlank、@Email、@Pattern等校验注解，Controller类上加@Validated，Spring Boot的spring-boot-starter-validation会自动完成校验并把错误信息封装成MethodArgumentNotValidException，全局异常处理器里统一返回友好提示。员工工号校验要求"字母+数字"格式，我用了@Pattern(regexp = "^[A-Za-z0-9]+$")，省了至少十行代码。

3.3 JWT登录认证与RBAC权限控制的实现思路

登录认证模块是论文里的重点章节，前端是登录页面，后端是从登录接口到拦截器再到权限校验的完整链路。我用了JWT + Spring Security的方案，如果基础薄一点，用拦截器手动校验JWT也是可行的，在论文里体现的思路是一样的。

流程大概是这样的：

1. 用户提交用户名和密码，后端调用AuthenticationManager进行认证。
2. 认证成功后，生成JWT字符串，里面包含用户的ID、用户名、角色编码等关键信息，用Base64编码但注意不是加密，敏感信息不要往里面塞。
3. 前端拿到Token后存储到localStorage，每次请求在请求头植入Authorization: Bearer token。
4. 后端配置一个JwtAuthenticationTokenFilter，继承OncePerRequestFilter，在请求进入Controller之前拦截并解析Token，把用户信息放入SecurityContextHolder。
5. Controller方法上用@PreAuthorize("hasRole('ADMIN')")做细粒度权限控制，依赖全局方法安全配置。

具体实现中有几个容易掉坑的地方。第一个是Token过期时间的设置——我设的是2小时，但实际使用中发现用户可能在页面停留很久然后突然操作失败。后来加了刷新Token机制，前端在Token过期前用旧Token调用刷新接口拿到新Token，但注意刷新接口要校验旧Token的签名，不能光看有效期。

第二个是接口放行策略。登录接口、验证码接口必须放行，Swagger文档路径在开发环境也要放行，但生产环境要关闭。Spring Security的SecurityFilterChain配置里用requestMatchers配好白名单和需要鉴权的路径，顺序很重要——更具体的匹配规则要放在前面。

第三个是密码存储，绝对禁止明文。我用了BCryptPasswordEncoder，encode()加密后入库，matches()校验密码。BCrypt算法自带盐，即使两个用户密码相同，存储的哈希也不同，安全性明显更可靠。

3.4 Redis缓存加速：能缓存的热点数据有哪些

引入Redis不是为了凑技术栈，而是系统中确实有大量高频率读取的低频变动数据。我在系统里重点缓存了三类内容：

• 登录Token签名信息：把用户和Token的关系存入Redis，设置过期时间，实现真正的无状态认证。
• 部门树结构：部门查询在组织架构页面频繁调用，但部门数据很少变动，缓存后直接省掉数据库压力。
• 数据字典：职位列表、学历、婚姻状况等下拉选项的数据字典，由字典服务统一读取Redis。

缓存设计要注意缓存穿透、缓存击穿、缓存雪崩三个经典问题。我的处理办法：

缓存穿透（查询不存在的记录导致Redis被击穿打到数据库）：采用缓存空值策略，查询结果为空时也在Redis缓存一个空对象加短期过期时间，比如60秒；同时对关键查询接口加了参数校验，工号格式不合法直接抛异常返回。

缓存击穿（热点key在过期瞬间大量请求打到数据库）：加和生成逻辑需要添加分布式锁。我用的是Redis的SETNX命令实现一个简单的锁，获取不到锁的线程短暂自旋等待，拿到锁的线程执行数据库查询并回填缓存。查询员工基础信息的接口用了这个策略，实测效果稳定。

缓存雪崩（大量key同时过期导致数据库承受巨大压力）：过期时间统一加了随机数，比如基础过期时间30分钟，每个key额外加上0到300秒的随机偏移，避免周期性集中失效。

这里要特别提醒：缓存和数据库的一致性不能完全依赖"先删缓存再更新数据库"这种简单方案，极端情况下还是会读到旧数据。我的策略是更新操作直接删缓存，并且给所有缓存key加上业务模块前缀统一管理，比如hr:dept:tree、hr:dict:positions，将来有问题可以整模块清理。

4. 核心功能模块实现与难点攻坚

4.1 员工信息管理的批量导入与数据校验

员工模块看似是普通的CRUD，但做到批量导入时就出现了真正的业务难度。导入Excel文件需要识别各种脏数据：手机号格式不对、入职日期在黑名单之外、部门名称不存在、身份证号位数不对。数据量大时如果全部入库才发现问题，整改成本很高。

我实现了一个三步走的导入流程：

1. 读取与解析：使用EasyExcel解析Excel文件，一行行读取为一个临时对象列表。
2. 逐行校验：校验规则包括必填项判断、字段格式判断、唯一性判断（工号不能重复）、外键有效性判断（部门ID必须存在）。校验不通过的行收集错误信息，标明行号和原因。
3. 批量写入：校验通过的数据用MyBatis-Plus的saveBatch批量插入，每条记录附上导入失败原因返回前端展示。

校验逻辑里我犯过一个低级错误：Excel中数值类型的数据读取后变成Double，手机号等长数字被解析成了科学计数法。解决方案是读取数字类型的自定义转换器，统一转成String并保留原始格式。这类经验写在论文中，比单纯的"实现代码展示"更有说服力。

4.2 考勤模块的日期计算与排班

考勤模块的难点在日期计算。系统要支持多种考勤规则：正常班（工作日9点到18点）、轮班制（不同班组按周期排班）、弹性上下班（允许晚到但要补时）。这些规则用"一张表存打卡记录"是远远不够的。

我在数据库中额外设计了排班表（schedule_rule），记录每个员工在某个时间段的上班时间、下班时间、休息日和排班周期。每个月生成考勤结果时，根据排班规则结合打卡记录自动计算每个工作日的状态。

到这一步，最复杂的部分是跨天排班——比如晚班从22:00持续到第二天6:00的情况，如果按自然日判断打卡时间就会判定为缺勤。处理办法是把考勤日期切割为"班次开始日"：晚班22:00上班属于今天，下班时间虽然跨天但依然归到今天这个班次计算。计算时用LocalDateTime判断时间点是否落在班次区间内，注意要处理午夜前后的边界值。

实际测试时我发现了一个更隐蔽的问题：员工忘记打卡的时候，系统默认判定为缺勤，但现实中员工可能只是忘打卡但确实在岗。最后我在考勤模块加了"补卡申请"流程，员工提交补卡申请后由部门主管审批，审批通过后考勤状态由缺勤修正为正常。这个功能在论文里写得很有亮点，因为它体现的是对业务场景的理解，而不仅仅是技术实现。

4.3 薪资模块的算法封装与消息通知

薪资模块直接关系到员工的切身利益，算法必须严谨。系统里的实发工资计算规则是：

code复制实发工资 = 基本工资 + 绩效奖金 - 迟到扣款 - 缺勤扣款 - 社保公积金扣除

迟到扣款按次计算，缺勤扣款按天计算。这些规则在Java里很简单，但企业将来规则调整怎么办？如果把所有计算逻辑硬编码，每次改动都要改代码重新部署。我做了两层设计：

• 第一层：基础参数配置表，存储各种扣款金额、社保比例、起征点等参数，管理员可在系统内修改。
• 第二层：一个独立的SalaryCalculator组件类，根据配置参数和考勤结果计算最终工资，并输出计算过程日志。

计算过程日志是没用对不便复盘时查账用的：每月薪资生成后，管理员可以点开某个员工的工资明细，看到各项收入的对应公式执行结果。这个设计在答辩时能有效地展示你的业务思考深度。

薪资计算完成后，我在公告模块里加了一个"薪资发放通知"：状态变为已发放后，系统自动向该员工创建一条站内消息。消息通知模块不需要引入消息队列那么多成本，数据库一张消息表加一个未读数标记就够用了。技术选型讲究适配场景，能用简单方案解决的就不要为了炫技引入过重的框架。

5. 系统测试与论文答辩高频提问点

5.1 功能性测试与性能测试怎么选用例

系统开发完成后，测试章节是论文中必要的组成部分。我用了一个很传统的思路来组织：功能性测试用例表 + 性能测试报告 + 结论分析。功能测试用例表大概长这样：

性能测试我用Jmeter对登录接口和员工列表分页查询接口做了一个简单压测：200个并发线程循环调用100次，登录接口的平均响应时间在320ms左右，员工列表在使用了Redis缓存之后平均响应时间只有80ms左右。这些数据填进论文里，配合一个简单的性能测试结论，整个章节就非常充实了。

5.2 答辩时Spring Boot的高频追问与回答思路

答辩环节如果被问到Spring Boot相关问题，下面的思路是我自己整理的回答框架，亲测有效：

问：为什么选择Spring Boot而不是传统的SSH或SSM？
回答思路：Spring Boot基于SSM发展而来，将Spring的繁琐配置自动化。开发者可以更专注于业务逻辑；内嵌Tomcat服务器省去了部署配置；起步依赖机制自动管理第三方兼容性；社区生态庞大，后续整合微服务、云原生更方便。

问：Spring Boot自动装配的原理是什么？
回答思路：按"约定优于配置"思想，启动类使用@EnableAutoConfiguration，借助AutoConfigurationImportSelector加载spring.factories中的自动配置类，配置类通过条件注解结合当前classpath依赖和容器状态，决定哪些配置生效。

问：为什么使用MyBatis而不是JPA？
回答思路：HR系统中存在大量多表关联、动态条件SQL、复杂统计查询，MyBatis的SQL掌控力更直观；SQL优化空间更可控，DBA审查也方便；MyBatis-Plus提供通用CRUD能显著提高单表操作效率。

问：如何处理缓存和数据库的一致性？
回答思路：更新数据库后主动删除对应缓存，下次查询时回填，配合短暂的过期时间兜底。不采用双写策略，避免数据库和缓存同时更新操作的原子性问题。

问：项目部署上线方案是怎样的？
回答思路：前端Nginx托管静态资源，后端打包成Jar包通过Docker容器运行，数据库使用MySQL 8的Docker容器，通过docker-compose统一编排管理，实现一键启停。

6. 项目部署：从打包到Docker上线

6.1 Maven多环境配置与打包策略

系统开发完成后需要部署上线，我用Maven的profile机制配置了多环境管理。application.yml文件下建立三个子文件：application-dev.yml（本地开发环境）、application-test.yml（测试环境）、application-prod.yml（生产环境）。

每个环境文件的配置项不同，主要是数据库地址、Redis地址、日志级别。本地用H2或本机MySQL，测试用测试库存数据，生产用云数据库。然后在pom.xml里配置profiles：

xml复制<profiles>
    <profile>
        <id>prod</id>
        <properties>
            <activatedProperties>prod</activatedProperties>
        </properties>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
</profiles>

打包命令是：

bash复制mvn clean package -DskipTests -Pprod

注意-Pprod指定激活的profile，打包产物是xxx.jar。Spring Boot的spring-boot-maven-plugin会把项目打成一个可执行的fat jar，里面包含所有依赖。启动时一个java -jar就够了。

这里有个小坑是Nginx代理后的前端资源404：因为后端接口前缀统一为/api，前端静态资源放在/路径，Nginx配置里需要分别处理这两个location规则。有一次前端页面正常打开但登录接口一直报404，排查半天发现就是接口路径配错，Nginx把/api/login请求代理到了/login。接口路径统一加前缀，在开发阶段就规划好，能省掉后续不少联调痛苦。

6.2 Docker打包Spring Boot项目的完整流程

Docker部署带来的最大好处是环境一致性——本地跑通的代码，到服务器上大概率也能跑通，再也不用担心"我这儿没问题啊"的经典甩锅理由。

第一步是编写Dockerfile：

dockerfile复制FROM openjdk:8-jre-slim
LABEL maintainer="yourname"
COPY target/hr-server.jar /app/hr-server.jar
WORKDIR /app
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "hr-server.jar", "--spring.profiles.active=prod"]

第二步是在项目根目录编写docker-compose.yml，一次编排后端、MySQL、Redis三个容器：

yaml复制version: '3'
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root123
      MYSQL_DATABASE: hr_system
    volumes:
      - mysql_data:/var/lib/mysql
    ports:
      - "3306:3306"
  redis:
    image: redis:6.2
    ports:
      - "6379:6379"
  app:
    build: .
    depends_on:
      - mysql
      - redis
    environment:
      SPRING_PROFILES_ACTIVE: prod
    ports:
      - "8080:8080"
volumes:
  mysql_data:

第三步是启动命令：

bash复制docker-compose up -d --build

启动后访问http://服务器IP:8080/api/v1/health检查后端健康状态。这里有三个注意点：一是容器内应用日志用docker-compose logs -f app查看，排查报错很方便；二是数据库初始化需要等MySQL容器完全就绪后再启动应用，depends_on只是控制启动顺序，不保证服务已就绪，我用了一个脚本循环检测3306端口通断后才启动应用容器；三是生产环境的MySQL数据一定要挂载volume持久化，否则容器一删数据全没了。

7. 常见问题与避坑指南

7.1 高频问题处理速查表

整个开发周期里，我给自己列了一个问题排查表，很多问题都是踩过一次之后才彻底明白的，分享几个最有代表性的：

最后一个字段类型问题值得展开：我用Long开局用了全局ID策略后，表主键却写成int，导致插入数据超过int范围直接报错。后来统一使用@TableId(type = IdType.ASSIGN_ID)并且数据库主键改为bigint，这个问题才彻底解决。写论文的时候把这个坑整理成表格配在测试章节，既展示了思考，也丰富了内容。

7.2 零碎但实用的小技巧集合

还有一些细节，不属于某个功能模块，但对项目感受影响很大：

关闭Swagger文档暴露。开发阶段方便调试，但生产环境绝对不能开着接口文档裸奔。Spring Boot 3用springdoc，配置springdoc.api-docs.enabled=false和springdoc.swagger-ui.enabled=false即可关闭。我在生产环境的profile里配置关闭，开发环境的profile保持开启。

自定义Banner。Spring Boot启动时默认输出Spring的ASCII艺术字，项目上线前换成自己的项目名和版本号，通过spring.banner.location指定自定义banner文件。虽然是不起眼的小事，但答辩演示时启动日志一眼看到项目名，观感会专业很多。

日志分级和持久化。用logback配置，logger按包名区分级别，业务日志输出到logs/hr-server.log，每天按日期滚动。排查生产问题没有日志寸步难行，这句话我反复强调很多次了，但每次帮别人看项目还是会遇到没配日志的情况。

接口幂等性。薪资发放这类重复提交后果严重的接口，我在前端提交时做了防重复点击，后端接收请求时用Redis存一个请求ID，如果同一请求ID处理过就直接返回上次结果。这个方案虽然朴素，但保障了极端情况下的数据安全。

IDEA开发小配置。Spring Boot项目在IDEA里运行，默认热部署需要手动重启。引入spring-boot-devtools依赖后，在application.yml配置spring.devtools.restart.enabled=true，修改代码后IDEA会自动重启应用。但注意生产环境不要带这个依赖，会降低启动性能且引起安全问题。

我之前把Spring Boot版本选得太高（3.2.x），结果很多第三方依赖还没有适配JDK 17的模块化限制。折腾了差不多一周后发现，毕设项目完全没必要追新版本，Spring Boot 2.7.x配合JDK 8或者11才是最稳的组合，生态兼容性最好，网上教程最多，遇到问题一搜就有答案。这个教训写在最后，希望后来人能少走弯路。版本选择的原则永远是"稳定优先，够用就好"，不是越新越好，尤其在毕业设计这种时间紧、任务重、试错成本高的场景下，稳妥压倒一切。