Spring 发布节奏转向五月，Spring Boot 4.1 正在酝酿什么

预计阅读时间：9 分钟

Spring 团队在 Office Hours 播客第五季第十六期中确认了一个重要变化：Spring 的发布列车（Release Train）时间窗口正在从传统的十一月周期向五月迁移。与此同时，他们也透露了 Spring Boot 4.1 的初步规划方向。对于正在维护 Spring 项目的工程师来说，这两个信号意味着升级节奏和依赖管理策略需要提前调整。

发布列车为什么转向五月

Spring 生态的多个项目——Spring Framework、Spring Boot、Spring Security、Spring Data 等——长期以来遵循十一月集中发布的节奏，形成所谓的"发布列车"。所有核心项目在同一时间窗口推出新大版本，方便用户一次性升级。

转向五月的原因主要有两个：

Jakarta EE 的发布周期调整。Jakarta EE 10 之后，规范组织的发布节奏发生了变化，Spring Framework 7 和 Spring Boot 4 需要紧跟 Jakarta EE 11 的规范基线。把发布窗口移到五月，能更好地与上游规范对齐，避免在十一月发布时还要等几个月才能拿到最终版规范。
社区反馈周期更合理。五月发布意味着夏季之前新版本就能进入社区验证阶段，秋季有足够时间收集问题并修复，到年底形成稳定版本。十一月发布则把验证期压到了年底假期和年初，反馈密度不够。

这个变化直接影响项目升级计划：如果你过去习惯在年初评估升级、年底动手，现在需要把评估窗口提前到第一季度，动手窗口提前到第二季度。

Spring Boot 4.1 的方向信号

播客中提到 Spring Boot 4.1 时，并没有给出完整的特性清单，但几个方向已经明确：

基于 Spring Framework 7

Spring Boot 4.x 系列将基于 Spring Framework 7。Spring Framework 6 引入了 Jakarta EE 9+ 基线和 GraalVM AOT 支持，Spring Framework 7 会在此基础上继续推进——更完整的 AOT 编译路径、对虚拟线程（Project Loom）的深度适配、以及更严格的 null-safety 注解约束。

Jakarta EE 11 基线

Spring Boot 4.0 将锁定 Jakarta EE 10，而 4.1 有望跟进 Jakarta EE 11。这意味着 jakarta.* 包命名已经稳定，但部分规范 API 会升级——比如 Jakarta Persistence 3.2 可能引入新的查询能力，Jakarta Validation 3.1 可能调整约束注解的行为。如果你的项目直接使用了这些规范 API，需要提前检查兼容性。

Observability 继续深化

Spring Boot 3.x 已经把 Micrometer Observation API 深度整合进了自动配置。4.1 会继续这个方向——更多的自动观测点、更方便的自定义 Trace 注入、以及与 OpenTelemetry SDK 1.x 的对齐。这意味着你现有的 Micrometer 配置大概率可以平滑迁移，但自定义 Instrumentation 的写法可能需要适配新 API。

提前准备：升级路径检查清单

既然发布节奏变了，现在就该为 Spring Boot 4.x 做准备。最实际的起点是确保你当前的项目已经站在 Spring Boot 3.x 的最新稳定版上。下面是一个可以直接运行的检查脚本和配置示例。

用 Maven 检查依赖基线

# 检查当前项目使用的 Spring Boot 版本
./mvnw dependency:tree -Dincludes=org.springframework.boot | grep "spring-boot-autoconfigure"

# 检查是否有 javax.* 包残留（Spring Boot 3.x 已经全面迁移到 jakarta.*）
./mvnw dependency:tree | grep "javax."

如果 grep "javax." 有输出，说明你的依赖里还有未迁移到 Jakarta 命名空间的库。这些库在 Spring Boot 4.x 下大概率会报 ClassNotFoundException，必须提前替换。

Gradle 版本对齐配置

如果你用 Gradle 管理 Spring Boot 项目，建议现在就把版本基线对齐到最新的 3.x，并显式声明 Spring Framework 版本，方便后续追踪：

// build.gradle
plugins {
    id 'java'
    id 'org.springframework.boot' version '3.4.1'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'

    // 确保 Jakarta 命名空间依赖
    implementation 'jakarta.persistence:jakarta.persistence-api'
    implementation 'jakarta.validation:jakarta.validation-api'

    // 替换任何仍在用 javax.* 的旧库
    // 例如：把旧版 hibernate-validator 换成 Jakarta 版
    // implementation 'org.hibernate.validator:hibernate-validator:8.0.2.Final'

    runtimeOnly 'org.postgresql:postgresql:42.7.4'

    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

// 显式追踪 Spring Framework 版本，为 4.x 升级做准备
configurations.all {
    resolutionStrategy.eachDependency { details ->
        if (details.requested.group == 'org.springframework') {
            details.useVersion '6.2.1'
        }
    }
}

Observability 配置先行适配

Spring Boot 4.1 的 Observability 变化主要在 API 层面，配置层基本不变。现在把 Actuator 和 Micrometer 配好，升级时改动最小：

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
  observations:
    enabled: true
  tracing:
    sampling:
      probability: 1.0
  metrics:
    tags:
      application: ${spring.application.name}
    export:
      prometheus:
        enabled: true
      otlp:
        enabled: true
        step: 30s

// 自定义 Observation 示例——4.1 中 API 可能微调，但注册模式不变
import io.micrometer.observation.Observation;
import io.micrometer.observation.ObservationRegistry;
import org.springframework.stereotype.Service;

@Service
public class OrderService {

    private final ObservationRegistry registry;

    public OrderService(ObservationRegistry registry) {
        this.registry = registry;
    }

    public String placeOrder(String productId) {
        return Observation.createNotStarted("order.place", registry)
                .lowCardinalityKeyValue("product.id", productId)
                .observe(() -> doPlaceOrder(productId));
    }

    private String doPlaceOrder(String productId) {
        // 实际业务逻辑
        return "ORDER-" + productId.hashCode();
    }
}

这段代码在 Spring Boot 3.4 下可以直接运行。当 4.1 发布时，ObservationRegistry 的核心用法不会变，只有底层传播机制（如 W3C TraceContext 处理）可能更新，你的业务代码几乎不需要改动。

升级节奏调整建议

时间节点	传统节奏（十一月发布）	新节奏（五月发布）
评估新版本	Q3（7-9月）	Q1（1-3月）
启动升级	Q4（10-12月）	Q2（4-6月）
稳定验证	Q1 次年（1-3月）	Q3（7-9月）

具体建议：

现在就站在 3.x 最新版上。Spring Boot 4.0 和 4.1 的迁移路径是从 3.x 平滑过渡，如果你还在 2.x，先完成 3.x 升级，否则跨两个大版本迁移的成本会非常高。
清理 javax.* 残留。这是从 3.x 到 4.x 最硬的门槛。用上面的 dependency:tree 命令扫一遍，逐个替换。
锁定 Java 17+ 基线。Spring Boot 4.x 不会支持 Java 8 或 11，最低基线是 17，推荐 21（虚拟线程需要 21+）。
关注 Spring Office Hours 播客。发布节奏和 4.1 特性细节会在后续几期持续更新，比等正式 Release Note 早几个月拿到信号。

五月发布列车意味着 Spring 生态的升级季节从年底挪到了年中。提前把依赖基线对齐、把 Observability 配置做稳，等到 Spring Boot 4.1 五月到站时，你只需要改一个版本号就能上车。