Spring 生态密集发布里程碑版本：如何评估 Boot、Framework 与 Data 全家桶

2026 年 9 月 21 日当周，Spring 生态进入了一轮密集的预发布周期。Spring Boot、Spring Framework、Spring Data、Spring Security、Spring Integration、Spring Batch、Spring AMQP、Spring for GraphQL 和 Spring for Apache Kafka 发布了第二个里程碑版本；Spring AI、Spring Cloud、Spring Web Services 与 Spring LDAP 则发布了首个里程碑版本。

这组消息的重要之处不只是“版本很多”，而是多个基础组件同时进入新一轮验证阶段。对于维护 Spring 应用的团队，这正是提前发现兼容性问题、评估迁移成本和验证构建链的窗口，但它并不意味着这些版本已经适合直接进入生产环境。

M1 与 M2 传递了什么信号

里程碑版本通常用于公开尚未稳定的新版本，让框架作者、库维护者和应用团队尽早验证 API、依赖关系及运行时行为。

M1 可以视为一条发布线第一次向外部开发者开放验证。此时 API、默认配置和依赖版本仍可能发生明显变化。M2 说明该发布线又经过了一轮迭代，但“第二个里程碑”仍不等于候选发布版，更不等于正式版。

因此，不能仅凭 M1 或 M2 判断升级风险。更有价值的判断依据包括：

• 是否出现弃用、删除或包名变化；
• 自动配置条件和默认属性是否改变；
• Java、Gradle、Maven 以及应用服务器的最低版本是否提高；
• Spring Security 过滤器链、Spring Data 查询生成等关键路径是否保持原有行为；
• 使用的第三方 starter 是否已经适配目标发布线。

来源摘要没有列出这些里程碑版本的具体功能变化，因此在实际评估时，应把各项目的发布说明、迁移指南和兼容性矩阵作为依据，而不是假设同一周发布的所有项目天然兼容。

不要把整个 Spring 组合一次性升级

Spring Boot 通常承担依赖管理和自动配置入口的角色。以 Boot 为核心的应用，应先选择目标 Boot 里程碑版本，再检查其依赖管理清单实际引入了哪些 Spring Framework、Data、Security 和 Integration 版本。

只有在应用直接使用某个项目的 BOM、插件或尚未被 Boot 管理的模块时，才适合单独覆盖该组件版本。任意混合不同发布线可能造成编译可以通过、启动或运行时却失败的问题，例如方法签名不一致、类缺失或自动配置条件不再匹配。

可以按风险拆分验证范围：

建立一个可重复的里程碑验证分支

可以这样实践：在现有 Maven 项目中把 Spring Boot 版本提取为属性，并为里程碑仓库建立独立 profile。运行前，将 REPLACE_WITH_MILESTONE_VERSION 替换为准备评估的真实版本号。

<properties>
    <java.version>21</java.version>
    <spring-boot.version>REPLACE_WITH_MILESTONE_VERSION</spring-boot.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>${spring-boot.version}</version>
        </plugin>
    </plugins>
</build>

<profiles>
    <profile>
        <id>spring-milestone</id>
        <repositories>
            <repository>
                <id>spring-milestones</id>
                <url>https://repo.spring.io/milestone</url>
            </repository>
        </repositories>
        <pluginRepositories>
            <pluginRepository>
                <id>spring-milestone-plugins</id>
                <url>https://repo.spring.io/milestone</url>
            </pluginRepository>
        </pluginRepositories>
    </profile>
</profiles>

随后在隔离分支中执行完整验证。下面的脚本可直接放到项目根目录运行；它要求项目使用 Maven Wrapper，并允许通过环境变量覆盖测试版本：

#!/usr/bin/env bash
set -euo pipefail

: "${BOOT_VERSION:?Set BOOT_VERSION to the milestone version under test}"

./mvnw -B -U -Pspring-milestone \
  -Dspring-boot.version="${BOOT_VERSION}" \
  clean verify

./mvnw -B -Pspring-milestone \
  -Dspring-boot.version="${BOOT_VERSION}" \
  dependency:tree \
  -Dincludes=org.springframework,org.springframework.boot,org.springframework.security

运行方式如下：

BOOT_VERSION='替换为实际里程碑版本' bash verify-milestone.sh

不要只看 BUILD SUCCESS。应把依赖树保存为 CI 构件，并与当前正式版本进行比较，确认没有意外覆盖 BOM 管理的版本。集成测试还应覆盖数据库迁移、消息消费、认证失败、重试和应用优雅关闭等真实路径。

采用前的工程检查表

里程碑版本最适合进入实验分支、兼容性流水线和库维护者的测试矩阵。生产系统一般应等待正式版；即使为了提前适配而部署 M1 或 M2，也应限定在可回滚、无关键数据的环境中。

升级评估可以按以下顺序收口：

1. 固定 JDK、构建工具和基础镜像，避免同时引入无关变量。
2. 优先通过 Spring Boot BOM 管理版本，不随意逐个覆盖 Framework、Data 或 Security。
3. 为编译告警、弃用 API 和配置属性变化建立清单。
4. 运行单元测试、集成测试、契约测试与启动探针。
5. 检查依赖树、软件物料清单和已知漏洞扫描结果。
6. 记录回滚条件，正式版本发布后重新执行同一套验证。

这一轮密集发布更适合作为“提前排雷”的时间点，而不是统一升级通知。越早把里程碑版本纳入自动化兼容性测试，正式版本到来时需要处理的未知问题就越少。