Java 21 微服务运行基线

zjc 于 2026-08-08 发布

这套微服务没有把 Java 版本当成随手可选的参数，而是明确固定在 Java 21。它决定了编译产物、Spring Boot 4 的运行要求、GC 行为、虚拟线程能力，以及测试工具链要支持的字节码版本。

一、版本只写在一处

<properties>
    <java.version>21</java.version>
    <maven.compiler.source>21</maven.compiler.source>
    <maven.compiler.target>21</maven.compiler.target>
</properties>

https://github.com/springvortex/spring-cloud-alibaba/blob/release/v1.0.0/pom.xml

父 POM 统一约束版本，业务模块不再各自声明。这对多模块项目很重要：一旦某个模块悄悄用不同字节码版本编译，部署时经常要到运行期才暴露。

二、它影响的不只是语法

Java 21 在这个项目里至少承担四件事：

  1. 支撑 Spring Boot 4.1 和当前依赖链的最低运行要求。
  2. 让 JaCoCo、Mockito、ByteBuddy 这类字节码工具明确适配目标。
  3. 保留使用虚拟线程、record、模式匹配等语言能力的空间。
  4. 让所有服务和 MP-Generator 共享同一套 JDK 认知，减少本机环境差异。

三、项目里的取舍

项目没有为了“新”而全面使用 Java 21 语法，而是先把它作为稳定基线。业务代码里更多还是清晰的面向对象写法；record 主要出现在网关这类边界模型上。这个顺序比较稳：先统一运行环境，再逐步吸收语言特性。

四、避坑点

  1. 本机 java -version 和 Maven 使用的 JDK 可能不是同一个。
  2. IDEA 的 Project SDK、Module Language Level、Maven Runner JDK 要一致。
  3. 升级依赖时要确认其是否支持 Java 21 字节码。
  4. 打包后的机器也要使用 JDK 21+，不要只保证编译机正确。

五、经验总结

Java 21 是整套工程的地基。它带来的价值不是某个单点语法，而是让框架、构建、测试和部署都围绕同一个运行时版本形成闭环。