Spring Boot 2.3.8 如何升级 Spring Framework 至 5.3.x？

Question

在使用 Spring Boot 2.3.8 时，如何安全地将底层 Spring Framework 升级至 5.3.x 版本？由于 Spring Boot 2.3.x 默认绑定 Spring Framework 5.2.14，直接通过 dependencyManagement 强制升级可能导致不兼容的 API 变更、自动配置失效或类加载错误。常见问题包括 `BeanCurrentlyInCreationException` 加剧、WebFlux 与 WebMvc 冲突、以及响应式组件行为异常。应如何评估升级影响，并通过依赖对齐、版本兼容性验证和逐步测试实现平滑迁移？

Answer 1

一、背景与升级动因

Spring Boot 2.3.8 是一个广泛使用的稳定版本，其底层默认集成的是 Spring Framework 5.2.14。随着 Spring 生态的演进，Spring Framework 5.3.x 引入了多项性能优化、安全修复和新特性（如对 Jakarta EE 9 的初步支持、响应式编程模型增强等）。对于长期维护的系统而言，升级至 5.3.x 能提升应用的健壮性与可维护性。

然而，直接通过 Maven 或 Gradle 的 <dependencyManagement> 强制升级 Spring Framework 版本存在较大风险。Spring Boot 的自动配置机制高度依赖特定版本的 Spring Framework API 行为，版本错配可能导致：

• BeanCurrentlyInCreationException 频繁出现，源于循环依赖处理逻辑变更
• WebFlux 与 WebMvc 共存时发生 DispatcherServlet 冲突
• 响应式组件（如 WebClient）行为异常或超时不一致
• 条件化自动配置（@ConditionalOnMissingBean 等）失效

二、影响评估：从依赖树到运行时行为

在实施任何升级前，必须进行完整的依赖兼容性分析。建议使用以下步骤：

1. 执行 mvn dependency:tree 或 gradle dependencies 查看当前所有 spring-* 模块的实际版本
2. 识别由 Spring Boot BOM 控制但可能被间接升级的模块，如 spring-core、spring-webmvc、spring-beans
3. 查阅 Spring 官方发布的 5.3 升级指南，重点关注 Breaking Changes
4. 检查项目中是否使用了已废弃或重构的类，例如 ReactiveAdapterRegistry 初始化方式变更

Spring 组件	Spring 5.2.14 中的行为	Spring 5.3.x 中的变化	潜在风险
BeanFactoryPostProcessor 执行顺序	宽松的初始化时机	更严格的上下文准备阶段约束	可能导致 Bean 提前初始化失败
WebFlux + WebMvc 共存	可通过配置隔离	DispatcherHandler 与 DispatcherServlet 冲突加剧	HTTP 请求路由混乱
Reactor Netty 超时设置	默认继承连接超时	需显式配置 .option(ChannelOption.CONNECT_TIMEOUT_MILLIS)	客户端连接挂起
CGLIB 代理生成	允许部分非法方法覆盖	增强校验导致 IllegalArgumentException	动态代理创建失败
ResourceLoader 处理 classpath*	递归扫描 JAR 包资源	引入缓存机制，可能遗漏更新后的资源	热部署场景下静态文件未刷新

三、依赖对齐策略与版本控制

为实现平滑迁移，应采用“渐进式依赖对齐”策略，避免全局强制升级。推荐做法如下：

<properties>
    <spring-framework.version>5.3.30</spring-framework.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${spring-framework.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring-framework.version}</version>
        </dependency>
        <!-- 仅升级核心模块，保持 webmvc/webflux 由 Boot 控制 -->
    </dependencies>
</dependencyManagement>

该策略确保关键基础组件先行升级，同时保留 Spring Boot 对高层模块的版本协调能力。

四、自动化测试与验证流程

构建一套分层验证体系是保障升级成功的关键。建议按以下流程执行：

graph TD A[准备阶段] --> B[冻结当前主干分支] B --> C[创建 feature/spring-fw-upgrade 分支] C --> D[局部升级核心模块] D --> E[单元测试回归] E --> F[集成测试验证 MVC/WebAPI] F --> G[启动端到端测试包括异步任务] G --> H[监控 Bean 初始化日志] H --> I{是否存在异常？} I -- 是 --> J[回退并定位冲突点] I -- 否 --> K[提交并通过代码评审]

五、常见问题排查与解决方案

在实际迁移过程中，以下问题是高频出现的典型场景：

• BeanCurrentlyInCreationException 加剧：Spring 5.3 加强了循环依赖检测，默认情况下不允许三级缓存之外的早期暴露。解决方案是在 application.properties 中启用宽松模式：
  spring.main.allow-circular-references=true
• WebFlux 与 WebMvc 冲突：当项目同时引入 spring-boot-starter-web 和 spring-boot-starter-webflux 时，Spring Boot 自动配置可能混淆 Reactive 与 Servlet 栈。应明确排除冲突依赖：

• <exclusions>
      <exclusion>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-reactor-netty</artifactId>
      </exclusion>
  </exclusions>

• 响应式链式调用阻塞：在混合使用 Reactor 与阻塞 IO 时，需确保线程调度正确。使用 publishOn() 切换到弹性线程池：

• webClient.get().retrieve()
              .bodyToMono(String.class)
              .publishOn(Schedulers.boundedElastic())
              .map(this::processBlockingCall);