Spring Boot 4.1 到底更新了什么？一份给开发者的升级清单

如果你这段时间一直在关注 Spring Boot 4.x，大概率会有一种感觉：

4.0 刚切到 Jakarta、Spring Framework 7、Java 新基线这条主线，很多项目还没完全消化完，4.1 又带来了一批面向工程化和生产环境的增强。

问题是，Spring Boot 4.1 的变化不少，如果只是逐条看官方说明，很容易记住一堆名词，却不知道真正该关注什么。

哪些是升级前必须检查的破坏性变化？

哪些是可以马上用起来的新能力？

哪些只是依赖版本滚动，不需要立刻改代码？

这篇文章不逐条翻译官方文档，而是把 Spring Boot 4.1 的主要变化整理成一份「开发者升级清单」。你可以按清单逐项检查自己的项目。

Spring Boot 4.1 升级清单总览

先看结论：Spring Boot 4.1 的 7 个重点

如果只用一分钟了解 Spring Boot 4.1，可以先记住这 7 件事：

1. 1. Spring Boot 4.0 中已废弃的 API，在 4.1 中开始被移除。
2. 2. gRPC 成为 Spring Boot 4.1 的重要新增能力。
3. 3. OpenTelemetry 和可观测性继续增强，配置项更多，也更接近标准环境变量。
4. 4. Jackson、HTTP Client、JDBC、Redis、Docker Compose 等常用基础设施都有细节增强。
5. 5. 构建工具链继续调整，Maven layers、Gradle build-info、bootBuildImage 都有变化。
6. 6. RabbitMQ / AMQP 相关能力需要谨慎评估，避免按过期资料盲目迁移。
7. 7. 依赖生态整体升级，Spring Data、Security、Kafka、Integration、Micrometer、OpenTelemetry 等都进入新一轮版本。

下面按「升级检查 → 新功能 → 运维观测 → 构建打包 → 依赖变化」的顺序展开。

1. 升级前先检查：4.0 废弃项已经开始清理

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

这意味着，如果你的项目在 4.0 升级时只是「能跑就行」，没有处理 IDE 或编译器里的 deprecated 警告，到了 4.1 可能就会直接变成编译错误。

建议第一步先做这件事：

mvn -DskipTests compile

或者：

./gradlew compileJava

然后重点看 deprecated API、配置属性和 starter 依赖。

尤其要注意 Derby。Apache Derby 项目已经宣布退休，Spring Boot 4.1 中对 Derby 的集成也进入 deprecated 状态，包括：

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

如果你只是在测试里用嵌入式数据库，优先考虑迁移到 H2 或 HSQL。

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

2. Java 与依赖基线：jOOQ 需要 Java 21+

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

这不是所有项目都会踩中的变化，但如果你的项目使用 jOOQ，就必须提前确认运行时和构建环境。

检查清单：

• • CI 使用的 JDK 是否已经是 Java 21+
• • 本地开发机是否统一 JDK 版本
• • Docker 镜像里的 JRE/JDK 是否匹配
• • Maven/Gradle toolchain 是否显式配置

很多团队升级 Spring Boot 时，只盯着 spring-boot-starter-parent 的版本，却忘了 CI 镜像、基础镜像、构建插件也可能跟不上。

结果就是：本地能跑，流水线挂了。

3. AOT 与测试跳过：不要再只依赖 -DskipTests

Spring Boot 4.1 里还有一个容易被忽略的构建变化：

你不能再依赖 Maven 命令中的 -DskipTests 来跳过测试 AOT 处理。

Spring Boot Maven Plugin 现在只响应 maven.test.skip，这是为了和其他 Maven 核心插件保持一致。

也就是说，如果你过去的 CI 命令是：

mvn package -DskipTests

现在需要重新检查它是否真的跳过了你想跳过的阶段。

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

mvn package -Dmaven.test.skip=true

这类变化看起来很小，但非常适合放进升级 checklist。因为它不会影响业务代码，却会影响构建时间和流水线行为。

4. gRPC 支持：4.1 最值得关注的新能力

Spring Boot 4.1 加入了 Spring gRPC 支持，并提供参考文档与 @GrpcAdvice 支持。

这说明 gRPC 不再只是生态里「自己拼装」的能力，而是进入 Spring Boot 官方自动配置体系。

官方能力包括：

• • 编写 gRPC Server
• • 编写 gRPC Client
• • 测试 gRPC 应用
• • 支持基于 Netty 的独立服务
• • 支持 Servlet 集成，通过 HTTP/2 暴露 gRPC
• • 新增 spring-boot-grpc-server
• • 新增 spring-boot-grpc-client
• • 新增 spring-boot-grpc-test
• • 提供 gRPC 参考文档
• • 支持 @GrpcAdvice

对后端团队来说，这个变化很关键。

过去你在 Spring Boot 项目里做 gRPC，往往要关心 starter、protobuf、server 生命周期、client 注入、测试支持等一堆细节。4.1 的方向是把这些能力纳入 Boot 的自动配置体验。

如果你的系统里有高性能内部 RPC、微服务间强类型通信、或者多语言服务协作，gRPC 支持值得重点跟进。

5. OpenTelemetry 与可观测性：配置越来越完整

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

首先，@Async 方法可以自动传播上下文。这意味着跨线程执行时，trace、observation 等上下文信息更容易保持一致。

其次，observation conventions 和 meter conventions 的自动应用也更完善。例如 Kafka、Rabbit、JVM memory、thread、class loading、CPU 等相关约定，都能更自然地接入自动配置。

OTLP 指标导出也支持压缩：

management.otlp.metrics.export.compression-mode=gzip

OpenTelemetry 相关增强包括：

• • 新增 management.opentelemetry.enabled
• • 可以禁用 OpenTelemetry SDK，并使用 no-op 实现
• • 新增 BatchLogRecordProcessor 配置
• • 新增 sampler 配置：management.opentelemetry.tracing.sampler
• • 支持 SpanLimits 和 LogLimits 自动配置
• • Micrometer OTLPRegistry 支持 exemplars
• • OTLP logging、metrics、trace exporters 支持 SSL bundle
• • 支持读取大部分 OpenTelemetry 环境变量，并映射到 Spring Boot 配置属性

这对云原生部署很有价值。因为很多平台更习惯通过环境变量注入观测配置，而不是写死在 application.yml 里。

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

6. Jackson 配置：从通用读写到 Factory 级别细调

Jackson 在 4.1 里也有几处重要增强。

CBOR、JSON、XML 等多格式通用的读写特性，可以通过下面两类属性自动配置：

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

Jackson factory 也支持配置：

• • spring.jackson.factory.*

这可以用来细调 Jackson 的 read/write constraints。

同时，Spring Boot 4.1 还支持更高级的 customizer callback：

• • JsonFactoryBuilderCustomizer
• • CborFactoryBuilderCustomizer
• • XmlFactoryBuilderCustomizer

自动配置的 JSON、XML、CBOR mapper 会使用 HandlerInstantiator，从 Spring ApplicationContext 中创建 handler 实例。

如果你的项目对 JSON 解析边界、XML 处理、CBOR 格式、反序列化安全或自定义 handler 有要求，这些变化都值得看。

7. HTTP Client 与安全：SSRF 缓解进入配置层

Spring Boot 4.1 中一个非常值得关注的变化是：阻塞式和响应式 HTTP Client 都可以配置 InetAddressFilter，用来阻止访问特定地址。

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

SSRF 的典型风险是：用户输入一个 URL，服务端代替用户发起请求，结果访问到了内网地址、云厂商元数据地址或其他敏感资源。

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

如果你的系统里有这些功能，建议重点关注：

• • webhook 回调
• • URL 预览
• • 文件导入
• • 第三方图片抓取
• • 远程配置读取
• • AI Agent 工具调用外部 URL

这类场景都可能触发 SSRF 风险。

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

8. JDBC、Redis、Docker Compose：日常开发体验继续补强

Spring Boot 4.1 还有一些看似零散、但很实用的增强。

JDBC lazy connection

Spring Boot 4.1 新增 spring.datasource.connection-fetch，可选值包括：

• • eager
• • lazy

当设置为 lazy 时，自动配置的连接池 DataSource 会被 LazyConnectionDataSourceProxy 包装，只有真正需要 JDBC statement 时才获取物理连接。

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

Redis Listener 自动配置

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

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

同时，spring-boot-starter-data-redis 现在也声明了对 spring-messaging 的依赖，因为这个功能需要它。

Docker Compose 失败日志

Docker Compose 支持也有增强：当调用 docker compose up 或 docker compose start 失败时，Spring Boot 会记录 docker compose logs 的输出。

日志级别由下面的属性控制：

spring.docker.compose.start.log-level=info

这对本地开发非常友好。以前 Compose 起不来，开发者还要自己去查容器日志；现在 Spring Boot 能在失败时直接带出更多上下文。

9. 构建与打包：Maven、Gradle、镜像构建都有变化

Spring Boot 4.1 在构建工具链上也有不少细节调整。

Gradle 插件的 bootBuildImage 任务支持通过命令行指定环境变量：

./gradlew bootBuildImage --environment BP_JVM_VERSION=21

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

BuildInfo Gradle 任务默认生成文件名调整为：

META-INF/build-info.properties

之前是：

build-info.properties

如果你有工具或脚本依赖旧路径，需要检查。

Maven plugin 支持从 classpath 加载 layers 配置。自定义 layers 可以放在：

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

并作为 plugin dependency 添加。

如果你的团队在做容器镜像分层优化，这个变化会让 layers 配置更容易复用。

10. RabbitMQ 与 AMQP：这块要特别谨慎

Spring Boot 4.1 对 RabbitMQ 和 AMQP 能力有过比较明显的调整方向，包括为 AMQP 1.0 支持做准备，以及探索 RabbitMQ 相关模块和 starter 的拆分。

这里建议团队保持谨慎。

RabbitMQ 和 AMQP 属于强基础设施能力，牵涉到依赖、starter、自动配置、连接工厂、消息监听容器和部署环境。任何迁移都不应该只看一段说明就直接改生产依赖。

更稳妥的做法是：

1. 1. 先确认你实际使用的 Spring Boot 4.1 版本。
2. 2. 再查对应版本的官方 Release Notes。
3. 3. 不要只根据早期资料改生产依赖。
4. 4. RabbitMQ/AMQP 相关升级单独建分支验证。
5. 5. 对消息发送、消费、重试、死信、事务、观测指标都跑一轮集成测试。

这类基础设施改动，重点不是「能不能编译」，而是「语义有没有变」。

11. Actuator、Info Endpoint 与证书信息

Spring Boot 4.1 中，info endpoint 增加了更多 process 信息：

• • process.uptime
• • process.startTime
• • process.currentTime
• • process.timezone
• • process.locale
• • process.workingDirectory

Actuator info endpoint 现在也会返回 truststore 中的 certificates。

同时，truststore 证书的过期时间也可以作为 metrics 暴露。

这类变化对平台团队和运维团队很有价值。

以前排查「服务到底启动多久了」「运行目录是什么」「证书什么时候过期」，往往要靠日志、脚本或额外探针。现在部分信息可以直接从 actuator 和 metrics 体系里拿到。

12. 依赖升级：不要只看 Spring，也要看第三方库

Spring Boot 4.1 升级了一批 Spring 项目和第三方依赖。

比较重要的 Spring 生态变化包括：

• • Spring Framework 7.0.x
• • Spring Data 2026.0.x
• • Spring Security 7.1.x
• • Spring Integration 7.1.x
• • Spring Kafka 4.1.x
• • Spring Session 4.1.x
• • Spring GraphQL 2.0.x
• • Spring gRPC 1.1.x
• • Micrometer 1.17.x
• • Micrometer Tracing 1.7.x

第三方依赖里也有不少关键项：

• • Flyway 12.x
• • OpenTelemetry 1.60.x
• • Rabbit AMQP Client 5.30.x
• • Rabbit Stream Client 1.6.x
• • Kotlin Serialization 1.11.x
• • Ehcache3 3.12.x

升级 Spring Boot，本质上也是升级一整套依赖管理矩阵。

如果你的项目对数据库迁移、消息队列、链路追踪、缓存、序列化非常敏感，建议不要只跑应用启动测试，还要跑完整集成测试。

最后给你一份升级检查表

如果你准备从 Spring Boot 4.0 升到 4.1，可以按下面这份清单走：

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

它更像是一次面向生产细节的补强：gRPC、OpenTelemetry、SSRF 防护、JDBC 连接获取、Redis Listener、Docker Compose 日志、构建分层配置，都在把框架体验往更完整的工程化方向推。

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

先拿这份清单过一遍。

再决定哪些变化立刻用，哪些变化先观望，哪些变化必须进测试计划。

有你踩过的 Spring Boot 4.1 升级坑，也欢迎在评论区补充。