Spring Modulith 多版本维护线迎来集中更新：如何稳妥跟进 2.2 M1 与补丁版本

Spring Modulith 同时发布了 2.2 M1、2.1.1、2.0.8 和 1.4.13。这组版本号传递出的重点，不只是“有新版本可升级”，而是项目正在并行维护多个版本线：2.2 M1 面向希望提前验证下一代能力的团队，其他三个版本则更适合已经投入生产、优先追求低变更风险的项目。

先区分里程碑版本与补丁版本

2.2 M1 中的 M1 表示第一个里程碑版本。它适合用于早期集成测试、兼容性验证和新功能预研，但不应仅因为版本号更新就直接替换生产环境依赖。里程碑版本可能仍会发生 API、默认配置或行为调整，升级前需要把验证范围从“能否编译”扩大到模块边界检查、事件处理、测试运行和部署流程。

2.1.1、2.0.8 和 1.4.13 属于不同维护线上的补丁更新。对于生产系统，选择与当前大版本一致的最新补丁版本，通常比跨大版本迁移更容易控制影响范围。不过，具体是否包含某个修复、是否要求同步升级 Spring Boot 或其他依赖，仍应以项目发布说明和兼容性要求为准。

可以把这次发布理解为两条工作流：

• 生产线：在当前支持的主版本内更新补丁版本，并运行回归验证。
• 试验线：单独创建升级分支或测试环境，评估 2.2 M1，不要让实验依赖直接进入稳定发布流程。

用版本矩阵管理升级决策

多版本同时发布时，最容易出现的问题是团队只记录“最新版本”，却没有记录每个服务当前使用的维护线。一个简单的版本矩阵可以把决策变成可审查的数据：

这里的 x 只是团队内部记录方式，实际构建文件应填写确定版本。不要把里程碑版本和补丁版本混在同一个发布候选中，否则出现问题时很难判断是业务代码变化还是框架版本变化造成的。

一个可直接改造的 Maven 配置示例

下面的示例使用 Maven 属性集中管理 Spring Modulith 版本。示例中的版本选择仅用于展示维护线管理方式；运行前请根据项目实际兼容性和官方发布信息确认依赖组合。

<properties>
    <!-- 生产服务使用已经选定的稳定维护线 -->
    <spring-modulith.version>2.1.1</spring-modulith.version>
</properties>

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

<dependencies>
    <dependency>
        <groupId>org.springframework.modulith</groupId>
        <artifactId>spring-modulith-starter-core</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.modulith</groupId>
        <artifactId>spring-modulith-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

将版本集中在一个属性中，有三个实际收益：升级补丁版本时不必逐个修改模块依赖；代码审查可以直接看到版本线变化；构建流水线也更容易针对不同维护线生成测试矩阵。对于验证 2.2 M1 的实验分支，可以只修改该属性，并把完整测试结果与稳定分支分开记录。

升级前可以先执行依赖树检查，确认没有旧版本被传递依赖重新带入：

./mvnw -U dependency:tree \
  -Dincludes=org.springframework.modulith

./mvnw -U clean verify

如果项目使用 Gradle，同样建议把版本放在统一的版本目录或扩展属性中，并检查依赖解析结果，而不是只看源码中的声明。

升级检查应覆盖模块行为

Spring Modulith 的价值在于帮助团队表达和验证应用模块边界，因此升级验证不能只停留在启动检查。可以重点检查以下内容：

1. 模块结构测试是否仍然通过，尤其是禁止跨模块访问的规则。
2. 应用事件的发布、监听和事务边界是否符合原有预期。
3. 模块文档、运行时模块信息或架构导出结果是否出现非预期变化。
4. 测试切片、集成测试和数据库初始化流程是否正常。
5. 打包、容器启动和预发布部署是否使用了同一套依赖版本。

对于 2.2 M1，还应额外记录可能变化的 API 和配置项。不要把“测试环境启动成功”当成里程碑版本可以生产上线的充分证据。更稳妥的做法是先让它服务于一两个边界清晰的模块，用真实用例观察升级影响，再决定是否扩大范围。

这次更新适合怎样落地

如果项目已经运行在 2.1.x、2.0.x 或 1.4.x，优先评估对应的 2.1.1、2.0.8 或 1.4.13。补丁升级也需要回归测试，但通常可以把变更范围控制在当前维护线上。

如果团队正在规划下一次大版本迁移，2.2 M1 可以作为兼容性雷达：在独立分支中编译、测试并记录差异，提前发现模块边界、事件处理或构建配置方面的问题。等稳定版本和兼容性结论更明确后，再安排正式迁移。

一个实用的落地清单是：

• 明确每个服务当前所在的 Spring Modulith 维护线。
• 生产服务先评估对应补丁版本，避免无目标地跨版本升级。
• 为 2.2 M1 建立隔离的实验分支和测试环境。
• 在 CI 中运行依赖树检查、模块结构测试和完整集成测试。
• 记录构建、部署、事件处理和模块架构结果，作为升级决策依据。

集中发布多个维护版本，为不同阶段的项目提供了选择空间。稳定维护线解决当前系统的风险控制，2.2 M1 则帮助团队提前获取下一版本的反馈；把两者分开管理，升级才会从一次仓促替换变成可验证、可回滚的工程流程。