前言

  2024 年再看 Java 后端项目，绕不开两个关键词：Java 21 和 Spring Boot 3。

  Java 21 是新的 LTS 版本，虚拟线程、Record Pattern、Sequenced Collection 这些能力都在把 Java 往更现代的方向推。Spring Boot 3 则把底层基线抬到了 Java 17 以上，同时全面切到 Jakarta EE 命名空间。

  但真正升级项目时，不能只看“能不能跑起来”。我的感觉是，第一步应该先把工程基线理顺。JDK、Maven、依赖版本、构建插件、运行镜像这些东西如果没统一，后面排查问题会很累。

先确认为什么要升级

  升级前最好先问清楚目标。是为了用 Java 21 的新特性？是为了跟上 Spring Boot 3 生态？还是因为老版本依赖安全风险太多？

不同目标会影响升级方式。

如果只是为了安全修复，可以先小步升级 Spring Boot 2.7 的补丁版本，再准备大版本迁移。如果是新项目，就没必要再从老基线开始，直接用 Java 21 和 Spring Boot 3 会更干净。

我比较不建议只因为“别人都升了”就改生产项目。技术升级一定会有成本，尤其是涉及框架大版本时，测试和回归要留足时间。

JDK 版本要统一

  项目里最怕的是开发环境、CI 环境、生产环境用的 JDK 不一致。

比如本地用 Java 21，CI 还在 Java 17，生产镜像是某个旧的 11 版本。这种情况下，有些问题只有上线后才暴露。

我会先把版本写清楚：

<properties>
    <java.version>21</java.version>
    <maven.compiler.release>21</maven.compiler.release>
</properties>

然后再检查 CI 配置和 Dockerfile。

FROM eclipse-temurin:21-jre

不一定非要用这个镜像，但要明确生产运行时到底是什么 JDK。不要只在文档里写“需要 Java 21”，实际构建脚本里却没有约束。

Maven 也要一起看

  升级 Java 版本时，Maven 插件经常会被忽略。

比如maven-compiler-plugin、maven-surefire-plugin、maven-jar-plugin这些插件如果太旧，可能会遇到奇怪的问题。尤其是测试插件，老版本对新 JDK 的支持不一定好。

一个简单的编译插件配置可以这样：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <release>21</release>
    </configuration>
</plugin>

如果是多模块项目，最好统一放在父工程的pluginManagement里。不要每个子模块自己写一套版本，不然后面会出现同一个项目里构建行为不一致。

依赖不要一次乱升

  升级 Spring Boot 3 时，很容易顺手把所有依赖都升到最新。这个做法看起来省事，但风险很高。

我的习惯是先让 Spring Boot 的依赖管理接管大部分版本。能不手写版本就不手写，尤其是 Jackson、Tomcat、Hibernate、Validation 这些和 Boot 强相关的库。

如果项目里有很多显式版本，可以先整理一遍：

1.必须固定版本的保留。 2.Spring Boot 已经管理的去掉。 3.长期不用的依赖删除。 4.内部组件单独列清楚兼容范围。

这一步很枯燥，但很有用。依赖越干净，大版本升级时越容易知道问题来自哪里。

配置也要做一次清理

  很多项目的application.yml里会留下历史配置。有些配置在新版本里已经改名，有些配置早就不生效了。

升级时可以顺手做一次清理。比如服务端口、连接池、日志、Actuator、序列化配置，都要看一遍。

我一般会特别关注这几类：

1.数据库连接池配置。 2.JPA 或 MyBatis 配置。 3.日志级别和日志格式。 4.Actuator 暴露端点。 5.序列化时间格式。

这些配置都和运行行为有关，不要只盯着启动是否成功。

小结

  Java 21 和 Spring Boot 3 的升级，不是把版本号一改就结束。工程基线如果没理顺，后面每一步都会变得不确定。

  我的建议是先统一 JDK、构建插件、依赖管理和运行镜像，再开始处理框架兼容问题。基础打稳以后，后面改 Jakarta、数据访问和线程模型，心里会有底很多。