Spring Boot 4.1 升级清单：这 12 个变化，开发团队要提前看

如果你刚把项目迁到 Spring Boot 4.0，看到 4.1 的 Release Notes，第一反应可能是：

又要升级了？

但 Spring Boot 4.1 并不是那种「只改几个依赖版本」的小版本。

它一边继续清理 Spring Boot 4.0 里已经废弃的东西，一边把 gRPC、OpenTelemetry、HTTP Client 安全、RabbitMQ Streams、Redis Listener、MongoDB Batch、JDBC 连接获取、构建插件等能力往前推了一步。

如果你只是把版本号从 4.0 改到 4.1，很可能会漏掉一些真正影响构建、测试、观测和安全边界的变化。

所以这篇不逐条翻译官方文档。

我把 Spring Boot 4.1.0 Release Notes 整理成一份「开发者升级清单」。你可以照着这 12 项逐一检查自己的项目。

Spring Boot 4.1 升级清单总览

先看结论：Spring Boot 4.1 最值得关注的 12 件事

如果你只想快速过一遍，可以先看这份总清单：

下面逐项展开。

1. 先清理历史债：Spring Boot 4.0 的废弃项已经开始移除

Spring Boot 4.1 中，一个最基础但最容易被忽略的变化是：

Spring Boot 4.0 里已经标记为 deprecated 的类、方法和属性，在 4.1 中被移除了。

这意味着什么？

如果你在升级到 4.0 时只是做到「应用能启动」，但没有处理 IDE、编译器或配置元数据里的 deprecated 警告，那么升级到 4.1 时，这些警告可能会变成真正的编译错误或启动错误。

建议第一步先做这件事：

mvn -DskipTests compile

或者：

./gradlew compileJava

然后重点检查三类东西：

• • 代码里直接调用的 deprecated API
• • application.yml / application.properties 里的 deprecated 配置项
• • 依赖里仍然使用旧 starter、旧模块或旧 jar mode 的地方

升级不是从改版本号开始，而是从清理历史债开始。

2. Derby 用户要注意：Spring Boot 集成已经进入废弃状态

Apache Derby 项目团队已经宣布项目退休。

因此，Spring Boot 4.1 中对 Derby 的集成也被标记为 deprecated。

受影响的典型项包括：

• • org.springframework.boot.jdbc.DatabaseDriver.DERBY
• • org.springframework.boot.jdbc.EmbeddedDatabaseConnection.DERBY

如果你的项目还在用 Derby，建议尽快评估替代方案。

更常见的场景是：很多团队并不是生产环境用 Derby，而是在测试、demo、旧模块或本地开发里用它。

这类场景可以优先考虑迁移到：

• • H2
• • HSQL

迁移前可以先全局搜一下：

grep -R "DERBY\|derby" .

别等到某次依赖升级后，测试环境突然起不来，才发现项目里还有一个几年前留下来的 Derby 配置。

3. Maven 构建要检查：-DskipTests 不再等于跳过测试 AOT

Spring Boot 4.1 对 Maven Plugin 的行为做了一个重要调整：

你不能再依赖 -DskipTests 来跳过测试 AOT processing。

Spring Boot Maven Plugin 现在只响应：

-Dmaven.test.skip=true

这是为了和其他 Maven 核心插件保持一致。

如果你的 CI 里有类似命令：

mvn package -DskipTests

建议重新确认它是否真的跳过了你期望跳过的阶段。

如果你的目标是完全跳过测试相关处理，应改成：

mvn package -Dmaven.test.skip=true

这类变化看起来很小，但非常适合放进升级 checklist。

因为它不一定影响业务代码，却可能影响构建耗时、CI 行为和 AOT 相关产物。

4. Java 版本别只看 Spring Boot：jOOQ 现在要求 Java 21+

Spring Boot 4.1 支持的 jOOQ 版本变为 3.20，而 jOOQ 3.20 要求 Java 21 或更高版本。

如果你的项目不用 jOOQ，可以跳过这一项。

但如果你用了 jOOQ，升级前至少要确认：

• • 本地开发 JDK 是否是 Java 21+
• • CI 构建镜像是否是 Java 21+
• • Docker runtime image 是否匹配
• • Maven / Gradle toolchain 是否显式指定
• • 代码生成任务是否在正确 JDK 下运行

很多团队升级 Spring Boot 时，只改了 spring-boot-starter-parent 或 BOM 版本。

结果是本地能跑，CI 挂了；CI 能过，容器镜像起不来。

这不是 Spring Boot 单独的问题，而是依赖矩阵升级带来的连锁反应。

Spring Boot 4.1 生产级增强

5. gRPC 成为重点新增能力：Server、Client、测试都进入 Boot 体系

Spring Boot 4.1 最值得关注的新能力之一，是 Spring gRPC 支持。

现在你可以用 Spring Boot 编写和测试 gRPC server 与 client 应用。

官方支持的方向包括：

• • 编写 gRPC Server
• • 编写 gRPC Client
• • 测试 gRPC 应用
• • 使用 Netty 运行独立 gRPC server
• • 通过 Servlet 集成，把 gRPC 暴露在 HTTP/2 上

如果你之前在 Spring Boot 项目里做过 gRPC，大概率知道痛点在哪里：

starter 怎么选？

server 生命周期怎么接？

client 怎么注入？

test support 怎么处理？

和 Boot 的自动配置、配置属性、测试体系怎么融合？

Spring Boot 4.1 的意义就在于：gRPC 不再只是「自己拼装一套生态」，而是开始进入 Spring Boot 官方工程化体验。

适合重点评估的场景包括：

• • 内部高性能 RPC
• • 微服务之间强类型通信
• • Java 与 Go / Python / Node 等多语言服务互通
• • 需要统一测试支持的 gRPC 服务

如果你的系统还停留在 REST 全家桶，未必需要马上迁移。

但如果你已经有 gRPC 存量代码，Spring Boot 4.1 值得单独拉分支验证。

6. Jackson 配置更细了：不只是 JSON，还包括 CBOR 和 XML

Spring Boot 4.1 对 Jackson 自动配置做了不少增强。

首先，跨格式通用的读写特性可以通过配置项统一设置：

spring.jackson.read.*
spring.jackson.write.*

这些能力适用于多个格式，例如：

• • JSON
• • CBOR
• • XML

其次，Jackson factories 也可以通过配置项调节：

spring.jackson.factory.*

这意味着你可以更细地控制 Jackson 读写约束。

如果需要更高级的定制，Spring Boot 4.1 还支持这些 callback：

• • JsonFactoryBuilderCustomizer
• • CborFactoryBuilderCustomizer
• • XmlFactoryBuilderCustomizer

另外，自动配置的 Jackson mapper 会使用 HandlerInstantiator，从 Spring ApplicationContext 里创建 handler 实例。

这对自定义序列化器、反序列化器、模块和 handler 的项目很有意义。

建议重点检查这些场景：

• • 你是否配置过 Jackson read/write feature
• • 是否有 JSON、XML、CBOR 多格式支持
• • 是否有自定义 serializer / deserializer
• • 是否对反序列化安全边界有要求
• • 是否在 handler 中依赖 Spring bean

Jackson 的变化不要只当成「序列化细节」。

在很多系统里，它直接影响 API 兼容性、输入校验、安全边界和跨服务数据格式。

7. HTTP Client 安全增强：SSRF 防护有了更标准的入口

Spring Boot 4.1 中，阻塞式和响应式 HTTP Client 都可以配置 InetAddressFilter。

它的作用是阻止出站请求访问特定地址。

官方也明确提到，这个能力适合用于缓解 SSRF 攻击。

SSRF 的典型风险是：

用户提交一个 URL，服务端替用户发请求，结果访问到了内网服务、云厂商元数据地址或其他敏感资源。

常见高风险场景包括：

• • webhook 回调
• • URL 预览
• • 远程文件导入
• • 第三方图片抓取
• • 用户自定义 API endpoint
• • AI Agent 工具调用外部 URL

以前这类安全边界往往散落在业务代码里。

Spring Boot 4.1 把出站请求过滤能力放到 HTTP Client 配置层，意味着团队可以更标准化地做安全加固。

只校验用户输入不够，出站请求也要有边界。

如果你的系统允许用户输入 URL，这一项建议优先评估。

8. 可观测性继续补强：OpenTelemetry 配置越来越完整

Spring Boot 4.1 对可观测性的增强非常密集。

先看一个很实用的变化：

@Async 方法可以自动传播 context。

这意味着当方法切到另一个线程执行时，trace、observation 等上下文更容易保持连续。

然后是 observation conventions 和 meter conventions 的自动应用更完整。

例如：

• • Kafka listener convention
• • KafkaTemplate convention
• • Rabbit listener / template / stream convention
• • JVM memory metrics convention
• • JVM thread metrics convention
• • class loading metrics convention
• • CPU metrics convention

OpenTelemetry 相关增强更多：

• • 新增 management.opentelemetry.enabled
• • 禁用 SDK 时使用 no-op SdkTracerProvider、SdkLoggerProvider、SdkMeterProvider
• • 新增 BatchLogRecordProcessor 配置
• • 新增 sampler 配置：management.opentelemetry.tracing.sampler
• • 支持 SpanLimits 自动配置
• • 支持 LogLimits 自动配置
• • Micrometer OtlpRegistry 支持 OTLP exemplars
• • OTLP logging、metrics、trace exporters 支持 SSL bundle
• • 支持读取大多数 OpenTelemetry 环境变量

如果你们的观测配置主要通过环境变量注入，这次尤其值得关注。

云原生部署里，很多配置不是写在 application.yml，而是由平台统一注入。

Spring Boot 4.1 对 OpenTelemetry 环境变量的支持，会让这类配置更接近标准化实践。

可观测性的趋势很清楚：少写胶水代码，多用标准配置。

9. RabbitMQ Streams 支持更完整：SSL、Service Connection 都要测

Spring Boot 4.1 对 RabbitMQ Streams 也做了增强。

首先，RabbitMQ Streams 支持 SSL 自动配置。

可以通过下面的配置开启：

spring.rabbitmq.stream.ssl.enabled=true

也可以通过 SSL bundle 配置：

spring.rabbitmq.stream.ssl.bundle=your-bundle-name

其次，RabbitMQ Streams 支持 Testcontainers 和 Docker Compose 的 service connection。

使用 Testcontainers 时，可以这样声明：

@ServiceConnection(type = RabbitStreamConnectionDetails.class)

但要注意，容器里还需要启用 rabbitmq_stream plugin。

如果使用 Docker Compose，需要映射 RabbitMQ Streams 的端口，例如 5552，并同样启用 rabbitmq_stream plugin。

这类能力很适合本地开发和集成测试。

但消息基础设施升级一定要谨慎。

建议至少验证：

• • SSL 握手是否正常
• • plugin 是否正确启用
• • Testcontainers service connection 是否生效
• • Docker Compose 本地环境是否可复现
• • 生产环境端口、防火墙和证书配置是否匹配

消息系统不是「应用能启动」就算升级成功。

真正要验证的是发送、消费、重试、顺序性、连接恢复和观测指标。

10. 数据访问与消息监听：MongoDB Batch、Redis Listener、JDBC lazy connection

Spring Boot 4.1 里有几项和日常业务很贴近的数据层增强。

10.1 Spring Batch 支持 MongoDB 自动配置

Spring Boot 4.1 为使用 MongoDB 的 Spring Batch 提供自动配置，并新增：

spring-boot-batch-data-mongo

如果需要在启动时自动创建 Spring Batch job 所需 schema，可以配置：

spring.batch.data.mongo.schema.initialize=true

默认会应用默认 schema，也可以提供自定义 newline-delimited JSON script。

如果你们以前为了 Batch + MongoDB 写过不少胶水配置，这次可以看一下官方自动配置是否能替代部分自定义代码。

10.2 @RedisListener 自动配置

Spring Boot 4.1 新增 Spring Data Redis @RedisListener endpoint 自动配置。

如果应用没有定义 RedisMessageListenerContainer，Spring Boot 会注册默认容器，让 listener 方法可以被发现和调用。

同时，spring-boot-starter-data-redis 现在也声明了 spring-messaging 依赖。

建议检查：

• • 是否已有自定义 RedisMessageListenerContainer
• • 是否需要使用 RedisMessageListenerContainerConfigurer
• • 是否依赖 starter 自动带入 spring-messaging
• • listener 线程模型和错误处理是否符合预期

10.3 JDBC lazy connection fetching

Spring Boot 4.1 新增：

spring.datasource.connection-fetch=lazy

当设置为 lazy 时，自动配置的 pooled DataSource 会被 LazyConnectionDataSourceProxy 包装。

也就是说，只有真正需要 JDBC statement 时，才从连接池获取物理连接。

这对减少无效连接占用、优化事务边界内的连接使用有帮助。

但它也属于会改变资源获取时机的配置，建议在真实业务路径里压测和验证。

11. 构建与打包变化：Gradle、Maven 都有细节调整

Spring Boot 4.1 对构建插件也做了不少调整。

11.1 Gradle bootBuildImage 支持命令行环境变量

现在可以在命令行里给 bootBuildImage 指定环境变量：

./gradlew bootBuildImage --environment BP_JVM_VERSION=21

如果同一个环境变量在命令行和 build script 中都配置了，命令行优先。

这对 CI/CD 很方便。

比如不同环境需要临时调整 buildpack 参数，就不一定要改构建脚本。

11.2 Gradle BuildInfo 默认文件名变化

BuildInfo Gradle task 默认生成文件名现在是：

META-INF/build-info.properties

之前是：

build-info.properties

如果你的脚本、监控、镜像构建或内部平台依赖旧路径，需要检查。

11.3 Maven Plugin 支持从 classpath 加载 layers 配置

Maven plugin 现在可以从 classpath 加载用于 repackaging 的 layers 配置。

自定义 layers 可以放在：

META-INF/spring/layers/<name>.xml

并作为 plugin dependency 添加。

如果你的团队在做容器镜像分层优化，这个变化很实用。

它可以让 layers 配置从「每个项目复制一份」变成「作为依赖复用」。

12. 依赖升级：这不是一个库的升级，而是一整套矩阵的升级

Spring Boot 4.1.0 同步升级了大量 Spring 生态项目。

其中比较关键的包括：

• • Micrometer 1.17.0
• • Micrometer Tracing 1.7.0
• • Reactor Bom 2025.0.6
• • Spring AMQP 4.1.0
• • Spring Data Bom 2026.0.0
• • Spring Framework 7.0.8
• • Spring GraphQL 2.0.4
• • Spring gRPC 1.1.0
• • Spring HATEOAS 3.1.0
• • Spring Integration 7.1.0
• • Spring Kafka 4.1.0
• • Spring LDAP 4.1.0
• • Spring Security 7.1.0
• • Spring Session 4.1.0

第三方依赖里，也有不少值得注意的版本：

• • Flyway 12.4.0
• • Hibernate Validator 9.1
• • OpenTelemetry 1.62.0
• • MySQL 9.7.0
• • MongoDB 5.8.0
• • Kotlin 2.3.21
• • Mockito 5.23.0
• • Selenium 4.43.0
• • SnakeYAML 2.6
• • jOOQ 3.21.5

所以升级 Spring Boot 4.1，本质上不是升级一个框架。

它是在升级你的 Web、Security、Data、Messaging、Observability、Build、Test、Database Driver 等一整套依赖矩阵。

建议至少对这些模块跑集成测试：

• • 登录、鉴权、JWT resource server
• • 数据库迁移和初始化
• • Kafka / RabbitMQ 消息发送消费
• • Redis listener 或缓存路径
• • OpenTelemetry tracing / metrics / logs
• • Batch job 启动与执行
• • Docker Compose 本地依赖启动
• • Native Image / AOT 相关构建

别只看应用能不能启动。

真正重要的是：核心业务路径和基础设施语义有没有变。

最后给你一份升级操作顺序

Spring Boot 4.1 升级执行路径

如果你准备升级到 Spring Boot 4.1，可以按这个顺序来：

1. 1. 先在 4.0 当前版本上清理 deprecated API 和配置项。
2. 2. 检查 Derby、layertools、旧配置属性等已废弃能力。
3. 3. 确认 Java 版本，尤其是使用 jOOQ 的项目。
4. 4. 修改 CI 中 Maven 跳过测试相关参数。
5. 5. 拉独立分支升级 Spring Boot 4.1。
6. 6. 跑编译、单元测试、集成测试。
7. 7. 单独验证 HTTP Client 出站请求和 SSRF 防护策略。
8. 8. 单独验证 OpenTelemetry、OTLP、metrics、logs、trace。
9. 9. 单独验证消息队列、Redis Listener、Batch、JDBC lazy connection。
10. 10. 检查 Gradle / Maven plugin 行为和镜像构建产物。
11. 11. 对核心业务路径做回归测试。
12. 12. 最后再决定哪些新能力立刻启用，哪些先观望。

Spring Boot 4.1 不是一个只有「大功能」的版本。

它更像是一次面向生产细节的补强：gRPC、OpenTelemetry、SSRF 防护、RabbitMQ Streams、Redis Listener、MongoDB Batch、JDBC lazy connection、构建分层配置，都在把 Spring Boot 的工程化能力继续往前推。

如果你的团队还停留在「能启动就算升级成功」，这次建议换一种方式：

先拿这份清单过一遍。

再决定哪些变化必须改，哪些变化可以用，哪些变化需要进测试计划。

你在升级 Spring Boot 4.1 时遇到过哪些坑，也欢迎在评论区补充。