Spring Boot 4.x / Spring Framework 7.1 迁移实务：JDK 21 基线、Jackson 3、RestClient 与 gRPC 该怎么改

Spring Boot 4.x / Spring Framework 7.1 迁移实务JDK 21 基线、Jackson 3、RestClient 与 gRPC 该怎么改本次迁移与以往小版本升级最大的差别不是“改几个依赖版本”而是同时抬高了语言基线、Jakarta 规范代际、序列化栈和 HTTP 客户端栈并为 AOT、gRPC 与安全能力引入了新的构建期和运行期约束。本文以 Spring 官方《Spring Framework 7.1 Release Notes》预览页为事实锚点 [1]把散落的升级点按破坏面与时间窗重排为一份可逐项打勾的迁移手册。一、迁移地图版本坐标、破坏面与本文路线1.1 Boot 4.x 与 Framework 7.x 的版本坐标Spring Framework 7.1 的官方 Release Notes 目前是一份预览页明确写着“计划于 2026 年 11 月发布”并列出从 7.0 升级到 7.1 的基线抬高与弃用项 [1]。这是本文唯一的一手来源也是判断“哪些变化已经确定、哪些还可能变”的基准。中文技术社区对 Spring Boot 4.x 的时间线描述存在明显冲突一篇整理文称 Spring Boot 4 “在 2023 年第四季度正式发布” [5]另一篇给出的表格称 4.0 GA 在 2025 年 11 月、4.1 在 2026 年 6 月、4.2 处于 M1 预览 [4]而一篇发布于 2026 年 7 月的文章称 Spring Boot 4.1.0 已正式发布 [3]。这些说法互不一致且这批资料的热度指标全部为 0 或缺失无法用“讨论热度”交叉验证。因此本文采取的立场是具体 GA 日期以 Spring 官方 releases 页面与官方 roadmap 为准本文不引用未经核实的日期结论。同样关于“3.4.x 及以下开源版本停止维护、商业支持 3.x 最高到 3.3.x”的说法来自二手整理 [3]排期决策前必须到官方 support policy 核对。至于 Boot 4.x 与 Framework 7.x 的精确对应关系例如 4.0 对应 7.0、4.1 是否对应 7.1二手资料同样没有给出可核验的映射表。本文在结构上只做“代际并行升级”的处理即Boot 4.0 代际变更与 Framework 7.0 的代际变更合并做Framework 7.1 的新增基线与弃用项作为下一窗口的预留改造。1.2 四类破坏面把升级点按“问题会在哪里暴露”分类比按特性分类更实用破坏面典型表现主要迁移点编译期找不到类、方法签名变化、注解包名错误javax → jakarta、Jackson 3、JSpecify、PropertyAccessorUtils 弃用运行期/启动期启动失败、自动配置条件不满足、序列化行为漂移Jakarta EE 11 容器基线、模块化与 starter 变化、Jackson 默认行为构建-原生期AOT 处理失败、native 镜像运行时找不到反射目标或资源AOT、GraalVM hints、gRPC 与动态代理安全面SSRF、越权访问内网、URL 校验绕过InetAddressFilter4.1[3]1.3 本文的使用方式建议按阶段推进每阶段独立验收、独立回滚阶段 0 盘点与门槛确认 → 阶段 1 Jakarta 容器基线 → 阶段 2 Jackson 3 → 阶段 3 HTTP 客户端 → 阶段 4 模块化与空安全 → 阶段 5 AOT/原生 → 阶段 6 gRPC → 最后处理 7.1 窗口的预留项。每完成一个阶段跑一次第十章对应的验收清单不要把多个阶段的改动混在同一个发布分支里否则一旦启动失败很难判断是命名空间问题还是序列化问题。资料可信度声明本文事实性结论分三级——一级为 Spring 官方 Release Notes [1]二级为可从公开 API 与最小工程复现的通用工程做法三级为中文二手整理文 [2][3][4][5]仅作线索凡引用其版本号、日期、支持策略之处均在正文标注“待核实”。二、阶段 0升级前盘点与门槛确认2.1 JDK 21 基线Spring Boot 4.0 代际被二手资料描述为“JDK 21 基线、Jakarta EE 11” [2][4]。这里的“基线”意味着编译目标、CI 镜像、容器基础镜像和运行时参数要同步前移而不仅仅是把 IDE 的 SDK 换掉。要一次性检查五处构建工具中的maven.compiler.release/source/targetGradle 为java.toolchainCI 执行镜像与 JDK 发行版Temurin、Corretto、Oracle 等需统一口径Docker 基础镜像例如eclipse-temurin:21-jre启动参数中的 GC、内存与模块开放参数旧的 CMS/已移除参数会在启动时直接报错字节码插桩、代理与混淆工具JaCoCo、Mockito、Lombok、MapStruct、ArchUnit 等是否支持 JDK 21 与新版字节码。如果团队还停留在 JDK 17第一步不是升 Spring而是先在 JDK 21 下把当前版本编译并跑绿把“JDK 升级问题”和“框架升级问题”分开归因。这是迁移实践中最重要的隔离手段。2.2 支持周期与升级窗口升级窗口的紧迫性取决于所用版本的支持状态。二手整理称 Spring Boot 每个版本生命周期约为一年、3.4.x 及以下开源维护已停止、商业支持 3.x 最高到 3.3.x [3]。这些是排期的关键输入但本文无法从一手资料核实务必以 Spring 官方支持策略页面为准。可以确定的是Spring Framework 7.1 的预览页确实标注计划于 2026 年 11 月发布 [1]团队应把 7.1 视为一个有明确时间窗的事件而不是遥远的规划项。2.3 依赖盘点把“有多少旧东西”量化不要凭印象判断。先做依赖树与字节码层面的扫描# Maven统计仍在传递依赖中出现的旧命名空间./mvnw dependency:tree-Dincludesjavax.*:*,jakarta.*:*|teejakarta-scan.txt# 进一步定位冲突形态同一功能出现两套命名空间./mvnw dependency:tree-Dverbose-Dincludes*validation*,*persistence*,*annotation*# Gradle 等价做法./gradlew dependencies--configurationruntimeClasspath|grep-Ejavax|jakarta# 字节码层面确认 class 文件是否引用了预期之外的包jdeps --multi-release21-recursivetarget/app.jar|grep-Ejavax\.|tools\.jackson|com\.fasterxml输出中值得关注的形态有两类一是“同一库的新旧两个坐标并存”二是“业务模块直接 import 了旧包但依赖树里只剩新包”。前者是依赖仲裁问题后者是代码问题处置方式完全不同。建议同时记录一张基线表JDK 版本、构建插件版本、依赖树快照、核心链路测试覆盖率、可回滚的上一版本制品。没有基线升级后出现的性能或行为差异无法判断是升级引入还是本来就存在。2.4 最小复现工程在动主工程之前搭一个只含三样东西的小工程一个 Controller、一次远程 HTTP 调用、一个对象与 JSON 的双向序列化测试。这个工程的价值在于后续每遇到“主工程跑不起来”的情况先在最小工程里复现能快速区分是框架行为变化还是项目自身配置问题。三、阶段 1Jakarta EE 11 与容器基线3.1 两种失败形态javax.*到jakarta.*的迁移会出现两种截然不同的症状很多团队只准备了第一种形态一编译失败或ClassNotFoundException/NoClassDefFoundError。特征明确编译器或类加载器直接报包名定位成本低。常见于校验注解、持久化注解、Servlet API、依赖注入注解仍引用旧包的代码。形态二注解静默失效。代码能编译、能启动但参数校验不触发、持久化映射不生效、序列化注解不被识别。根因是同一个类被新旧两套注解“重复标注”或运行时只有一套注解被框架扫描。这种问题比编译失败危险得多因为它只会在运行期以数据异常的形式暴露。排查顺序建议固定为启动异常栈 → 是否命名空间残留 → 是否传递依赖带入旧坐标 → 是否容器 API 版本不匹配Servlet 6.1 等→ 是否自动配置条件不满足。3.2 内嵌容器与外置容器Spring Boot 4.0 代际对应 Jakarta EE 11二手资料提到 Servlet 6.1 与内嵌容器适配 [2]。迁移时需要分别验证内嵌容器Tomcat / Jetty / Undertow随 Boot 版本升级重点验证过滤器链顺序、异步请求、错误页与静态资源外置容器部署时容器自身的 Jakarta API 版本必须与应用编译目标一致否则会出现“本地起得来、部署环境找不到类”自定义WebMvcConfigurer、Filter、ServletContextInitializer中残留的javax.servlet引用是最常见的编译期报错集中地。校验与持久化注解的包替换要整批完成不要只替换编译器报错的那几个因为未被编译器引用的注解例如只在配置文件或 XML 中出现的不会报错却仍然会静默失效。四、阶段 2Jackson 3 迁移——序列化全链路4.1 为什么这是“全链路”改造Spring Framework 7.1 的基线要求把 Jackson 提升到 3.1以获得 LTS 支持 [1]。Jackson 3 不是简单的版本号加一它涉及包名与模块坐标变化、构建方式从可变的ObjectMapper配置转向更偏向 builder 的配置模型、以及 Spring 侧适配入口的调整。二手整理也把“Jackson 3 全栈升级”列为 Boot 4.0 的核心变化之一 [2]。需要明确的不确定性Jackson 3 的确切包名前缀、模块 artifact 坐标、以及 Spring 中替代ObjectMapper定制入口的最终类名本批资料未提供可核验的一手信息。下文所有 Jackson 3 代码位置均以“待核实”标注落地时请对照 Jackson 官方 3.x 迁移指南与 Spring 7.x Javadoc 填写。迁移需要覆盖至少三处定制点定制点Jackson 2 典型写法Jackson 3 迁移方向核实状态MVC 消息转换自定义MappingJackson2HttpMessageConverter改用 Jackson 3 对应 converter类名待核实待核实HTTP 客户端RestTemplate上设置ObjectMapperRestClient的 message converter 配置待核实消息中间件Kafka/RocketMQ 的JsonSerializer指定 mapper适配 Jackson 3 的 serializer/反序列化器待核实全局配置可变ObjectMapper单例 configure(...)builder 构建、不可变实例待核实4.2 行为回归用快照防“静默漂移”日期格式、空值序列化、未知字段策略、枚举命名策略、时区处理这些默认行为一旦变化接口不会报错只会产出“客户端解析不了的 JSON”。唯一的防护是契约测试classOrderSerializationContractTest{// 伪签名Jackson 3 的构建入口以官方文档为准// JsonMapper mapper JsonMapper.builder().build();Testvoidorder_should_serialize_to_frozen_snapshot(){OrderordernewOrder(O-1001,OffsetDateTime.parse(2026-11-05T10:15:3008:00),null,List.of(newItem(SKU-1,2)));Stringjsonmapper.writeValueAsString(order);// 与版本库中的黄金文件比对而不是与 Java 字符串字面量比对StringexpectedreadResource(/snapshots/order-v1.json);assertEquals(expected,json);}}黄金文件放在src/test/resources/snapshots任何默认行为变化都会让快照 diff 直接可见。多模块工程里要防止新旧 Jackson 并存用依赖管理统一版本并在 CI 中加入“禁止旧坐标”的 Enforcer 或自定义检查否则同一个请求里可能一部分字段由新序列化器处理、另一部分由旧的处理。一个可以预见的推演场景非实测案例日期字段从带时区的字符串变为 epoch 数字前端仍按 ISO 字符串解析结果是“服务端无异常、客户端全部解析失败”。这类问题只有快照测试能提前拦住。五、阶段 3HTTP 客户端栈——RestTemplate → RestClient / HTTP Interface5.1 能力对照二手资料把“RestTemplate 弃用、改用 RestClient / HTTP Interface”列为 Boot 4.0 的明确变化 [2]。迁移的正确理解不是“换个客户端类”而是把散落的调用点收敛为接口化的远程访问层关注点RestTemplateRestClient / HTTP Interface调用风格模板方法 URL 字符串 可变参数同步流式 builder或HttpExchange接口 代理工厂异常体系RestClientException系列同属 Spring 异常体系但状态码处理通过 status handler 声明拦截ClientHttpRequestInterceptor同样支持拦截器注册入口不同序列化与 Jackson 2 强绑定的 converterconverter 体系重构Jackson 3 需重新接线可观测性自行埋点与 Micrometer/Tracing 集成的接入点更集中可测试性常用 MockRestServiceServer 或本地 stub建议以接口门面 测试替身隔离下面给出同一业务接口的两种写法API 签名请以当前版本 Javadoc 核对// 业务门面先抽象接口屏蔽客户端实现publicinterfaceOrderRemoteService{OrderViewgetOrder(StringorderId);}// RestClient 实现Spring 6.1 起可用Boot 4.x 中继续演进publicfinalclassRestClientOrderServiceimplementsOrderRemoteService{privatefinalRestClientrestClient;publicRestClientOrderService(RestClient.Builderbuilder,OrderClientPropsprops){this.restClientbuilder.baseUrl(props.baseUrl()).defaultHeader(HttpHeaders.ACCEPT,application/json).defaultStatusHandler(HttpStatusCode::is4xxClientError,(req,res)-{thrownewOrderNotFoundException(req.getURI(),res.getStatusCode());}).build();}OverridepublicOrderViewgetOrder(StringorderId){returnrestClient.get().uri(/orders/{id},orderId).retrieve().body(OrderView.class);}}// HTTP Interface 写法把远程调用定义成 Java 接口HttpExchange(/orders)publicinterfaceOrderApi{GetExchange(/{id})OrderViewgetOrder(PathVariableStringid);}// 代理工厂的构造方式随版本有调整以下为示意// OrderApi api HttpServiceProxyFactory// .builderFor(RestClientAdapter.create(restClient))// .build()// .createClient(OrderApi.class);HTTP Interface 的价值在于远程调用可以像本地接口一样被 mock、被 AOP、被静态检查测试不再依赖真实网络。但要注意它把“URL 拼接错误”从运行期挪到了编译期之外——路径写错依然只能在运行时暴露因此契约测试不可省略。5.2 渐进替换策略不要一次性重写。推荐三步抽门面把所有RestTemplate调用点收敛到OrderRemoteService这类接口后面业务代码只依赖接口双实现并存接口下保留RestTemplate与RestClient两个实现用配置开关切换灰度期对比两者返回结构逐模块切换每替换完一个模块跑一次该模块的契约测试与超时/重试语义验证再删旧实现。超时是必须显式迁移的语义。RestTemplate 常用HttpComponentsClientHttpRequestFactory或SimpleClientHttpRequestFactory设置连接/读取超时RestClient 侧对应的是请求工厂的配置入口。迁移时要把每个远程依赖的连接超时、读取超时、重试次数、幂等性判断列成表格逐项对照尤其注意“默认不重试”与“默认重试”的差异会在下游抖动时造成完全不同的故障形态。5.3 InetAddressFilterHTTP 客户端侧的 SSRF 防护二手资料称 Spring Boot 4.1 为 HTTP Client 增加InetAddressFilter用于防 SSRF服务端请求伪造[3][4]。SSRF 的攻击面是外部可控的 URL 参数被服务端用来发起请求攻击者指向内网地址、云元数据地址如169.254.169.254或环回地址从而把服务端变成内网探测的跳板。从工程角度这类过滤器的验证点包括默认策略是白名单放行还是黑名单拒绝过滤发生在“解析前的主机名”还是“解析后的 IP”这决定能否防住 DNS 重绑定同一域名第一次解析到公网、第二次解析到内网是否覆盖重定向跟随302 到内网地址是最常见的绕过路径IPv6、十进制 IP、混合格式主机名等编码变体是否被正确归一化与自定义ClientHttpRequestFactory、代理设置的叠加行为。核实要求InetAddressFilter的确切类名、所属模块Framework 还是 Boot 自动配置、配置属性名与默认策略本批资料没有给出本文不虚构。落地时请以 Boot 4.1 的官方文档与配置元数据spring-configuration-metadata.json为准。即便框架提供了过滤器业务侧仍应坚持“URL 由服务端白名单生成、不接受任意 URL 输入”的基本原则过滤器是纵深防御不是唯一防线。六、阶段 4模块化、JSpecify 空安全与 API 退役6.1 代码库模块化二手资料称 Boot 4.0 完成了“代码库完整模块化”并称其为最核心的架构变更 [2]。需要核实的关键点这次模块化是 Spring Boot 项目自身的构建内部重构还是用户可见的 starter/自动配置坐标变化。这直接决定迁移工作量——前者基本无感后者意味着依赖声明要改。在官方模块清单核实之前建议在迁移分支中把依赖收敛到 BOM 管理、避免直接锁定传递依赖版本这样无论模块如何拆分受到的冲击都最小。6.2 JSpecify 空安全二手资料提到 Boot 4.0 采用 JSpecify 空安全注解 [2]。JSpecify 的核心注解是类级NullMarked与元素级Nullable位于org.jspecify.annotationsNullMarkedpublicclassPricingService{privatefinalDiscountRepositoryrepository;publicPricingService(DiscountRepositoryrepository){this.repositoryrepository;}// 声明在 NullMarked 作用域内返回值默认非空publicBigDecimalpriceOf(Stringsku){BigDecimaldiscountrepository.findDiscount(sku);returndiscountnull?BigDecimal.ZERO:discount;}// 显式标注可空返回值NullablepublicStringlastModifierOf(Stringsku){returnrepository.findLastModifier(sku);}}引入后IDE 与静态检查工具会一次性报出大量存量告警。建议按三级处置告警类型含义处置优先级真实缺陷调用方未判空即解引用补判空或改契约高契约缺失方法可能返回 null 但未标注补Nullable或收紧实现中噪声泛型、数组、第三方类型推断不准局部抑制并记录低批量改造的原则是“先标注现状再逐步收紧契约”不要在同一次提交里既补注解又改行为。构建期检查工具Error Prone、NullAway 或 IDE 检查的接入参数需按所选工具的官方文档配置本文不给出未经核实的插件坐标。6.3 API 退役预告PropertyAccessorUtils → PropertyPathSpring Framework 7.1 已明确把org.springframework.beans.PropertyAccessorUtils标记为弃用改用新的PropertyPath类型及其专用解析器官方说明称新解析器带来更严格的属性路径语法与解析规则 [1]。这属于“7.1 提示弃用、后续版本移除”的典型条目现在的最佳动作是提前改造// 旧手工拼接/拆解属性路径字符串// String path prefix . property;// 新使用 PropertyPath 与专用解析器方法名以官方 Javadoc 为准// PropertyPath path PropertyPath.parse(prefix . property);更严格的语法意味着以前“碰巧能解析”的表达式可能直接抛解析异常。需要重点回归的表达式形态包括集合索引items[0].sku、嵌套下划线命名order_detail_no、空段a..b、以数字开头的段。建议在升级前先用脚本把全项目的 SpEL / 数据绑定表达式抽出来跑一遍解析。七、阶段 5AOT 与 GraalVM 原生镜像二手资料称 Boot 4.0 中 AOT 与 GraalVM 原生镜像从实验特性走向更成熟的生产支持 [2]。这句话的支持等级、要求的 GraalVM 版本与已知限制需以官方文档核对后填写到团队的构建规范中。AOT 处理位于构建链的前半段process-aot阶段分析 Bean 定义、生成配置代码与 hints产出由native-image阶段消费。只在 native 模式下暴露的问题绝大多数来自三类反射目标缺失、资源文件未注册、动态代理未生成。classOrderModuleHintsimplementsRuntimeHintsRegistrar{OverridepublicvoidregisterHints(RuntimeHintshints,ClassLoaderclassLoader){// 反射JSON 反序列化目标类型hints.reflection().registerType(OrderView.class,MemberCategory.values());// 资源模板、配置片段hints.resources().registerPattern(templates/order-*.json);}}native 失败症状缺失 hints 类型修复方向NoSuchMethodException/ 构造器找不到反射 hints注册类型与构造器资源读取返回 null资源 hints注册资源模式代理类创建失败代理 hints注册代理接口反射调用在 JVM 正常、native 报错提示未被 AOT 扫描检查是否动态注册 Bean验收门槛建议设为同一套契约测试在 JVM 模式与 native 模式双绿。CI 上把 native 构建放在独立 job按提交频率决定是每日构建还是合入主干触发控制时长与成本。八、阶段 6gRPC 官方支持4.1落地要点二手资料称 Spring Boot 4.1 提供了 gRPC 官方支持并将其视为微服务通信能力的补齐 [3][4]。必须核实的问题这究竟是 Spring Boot 内的 starter 级官方集成还是通过独立项目对接artifact 坐标是什么是否处于实验状态。在官方项目页确认之前本文不给出具体依赖坐标也不虚构注解与类名。下面只描述落地时必须解决的工程问题。契约管理.proto文件应作为一等公民进版本库明确生成代码的目录、生成插件版本与兼容规则字段号不可复用、保留字段。代码生成建议放在独立模块避免生成代码污染业务模块的编译缓存。与 HTTP 栈共存gRPC 服务与既有 REST 端点可以在同一应用内并存但要注意线程模型差异——gRPC 倾向于长连接与流式处理与虚拟线程、连接池、反向代理超时配置都需要重新核对。阶段 3 的 HTTP 客户端迁移与阶段 6 的 gRPC 引入建议分批进行避免同一次改动中同时出现两套通信栈的语义变化。生产化配套超时、重试、熔断、截止时间传播deadline、错误码映射、追踪维度服务名、方法名、状态码需要在引入时就配置而不是上线后补。原生镜像下还需额外验证 gRPC 相关的反射与代理 hints。REST 与 gRPC 的运维差异对照以官方文档核实后补充具体数值维度REST/HTTPgRPC契约OpenAPI/JSON Schemaprotobuf .proto传输文本、可缓存二进制、HTTP/2超时语义客户端超时为主deadline 逐跳传播错误传播HTTP 状态码gRPC status code可观测性访问日志成熟需补 tracing/metrics 维度九、Spring Framework 7.1 版本窗口计划 2026 年 11 月Spring Framework 7.1 的官方预览页目前列出的变更如下 [1]条目7.1 变化影响场景迁移动作核实状态发布时间计划 2026 年 11 月排期留出升级窗口官方预览页 [1]措辞可能变更Jackson基线提升至 3.1以获得 LTS 支持全部 JSON 序列化链路提前升到 3.1 并跑快照测试官方 [1]Hibernate ORM要求/支持 7.3JPA 持久化核对 BOM 与传递依赖提前试升官方 [1]具体是“最低版本”还是“新增支持”需对照原文Apache Derby支持被弃用嵌入式数据源、测试数据库评估替换数据库H2/PostgreSQL 等官方 [1]波及类需核实PropertyAccessorUtils弃用改用PropertyPath与专用解析器表达式解析、数据绑定提前改造表达式官方 [1]数据绑定预览页提及面向预期输入的模型对象或allowedFields一类收窄手段表单/参数绑定核对原文后评估绑定面收窄官方 [1]表述片段不完整需回原文核对Derby 需要特别说明官方明确写到 Apache Derby 项目自 2023 年起已退役因此本版本弃用对其支持 [1]。受影响最直接的是把 Derby 用作嵌入式开发库或集成测试数据库的工程。替换时要同步评估 SQL 方言差异、事务隔离级别与测试数据初始化脚本不要只换 JDBC URL。排期建议把“7.1 前置改造”拆成可以在当前迭代完成的小任务——提前升 Jackson 3.1、提前把表达式改到 PropertyPath、提前把 Derby 从测试栈中移除。这样 7.1 正式发布时升级就只是版本号变更加回归而不是又一次大规模改造。十、可执行迁移踩坑清单10.1 分阶段验收清单#阶段检查项验收标准常见症状处置参考章节10JDK 21 编译主工程与全部模块编译通过插件不识别新字节码升级构建插件二20CI 镜像构建与运行镜像统一 JDK 21本地通过、CI 失败统一 toolchain二30启动参数无已移除 JVM 参数启动即报错清理 GC 参数二40依赖树快照留档dependency:tree输出无法定位引入源保留基线文件二50回滚制品上一版本可部署制品与配置齐全回滚缺配置归档配置二61命名空间扫描无javax.*引用残留ClassNotFoundException全量替换注解三71校验注解参数校验测试生效校验静默失效检查重复注解三81持久化注解实体映射测试通过字段不入库核对包名三91内嵌容器过滤器链、错误页测试通过404/500 行为变化调整配置三101外置容器部署环境启动成功部署环境缺类对齐容器版本三112Jackson 版本统一全模块同一序列化栈新旧 Jackson 并存BOM 收敛 Enforcer四122序列化快照黄金文件测试全绿日期/空值格式漂移调整配置并更新快照四132MVC 转换器接口响应契约测试通过客户端解析失败重接 converter四142消息序列化MQ 收发契约测试通过消费端反序列化失败同步调整序列化器四153门面抽象业务代码不直接依赖客户端类调用点散落抽接口五163超时语义每个远程依赖有明确超时表线程被长请求占满显式配置超时五173错误处理4xx/5xx 映射到业务异常错误被吞配置 status handler五183并存灰度开关可切换新旧实现无法快速回退加开关五193SSRF 防护内网/环回地址被拒绝可访问内网配置并验证 InetAddressFilter五203重定向验证重定向到内网被拦截绕过过滤关闭或过滤重定向五214依赖声明传递依赖不被直接锁定模块化后缺类收敛到 BOM六224空安全告警高优先级告警清零大量 NPE 告警三级处置六234表达式解析全量表达式可解析解析异常迁移 PropertyPath六245AOT 构建process-aot无错误AOT 阶段失败定位具体 Bean七255反射 hintsnative 下 JSON 反序列化通过找不到构造器注册 hints七265资源 hints模板/配置可读取资源缺失注册资源模式七275双模式回归JVM 与 native 契约测试双绿仅 native 失败补 hints七286proto 管理契约进版本库且生成可控生成代码漂移固定插件版本八296超时/重试deadline 与重试策略配置生效故障扩散显式配置八306追踪维度tracing/metrics 可观测调用链断裂补埋点八317.1Jackson 3.1版本满足基线升级后启动失败提前升级九327.1Hibernate 7.3持久化回归通过映射/方言问题对照迁移指南九337.1Derby 退场测试栈已替换测试数据库不可用换 H2/PostgreSQL九347.1PropertyPath无弃用 API 调用编译告警批量替换九10.2 高频踩坑速查表症状判别手段根因处置ClassNotFoundException: javax.xxx依赖树 grepjavax传递依赖或代码残留换依赖坐标、全量替换包名启动成功但校验不生效写一个故意非法的请求新旧注解混用统一到 jakarta 注解JSON 字段格式突变黄金文件 diffJackson 默认行为变化显式配置序列化特性客户端超时但服务端正常抓包看响应耗时新客户端默认超时不同显式设置超时迁移后线程池被打满线程 dump无超时导致慢请求堆积配超时 限流JVM 正常、native 启动失败native 模式单独跑缺反射/资源/代理 hints补 RuntimeHintsnative 下 JSON 反序列化为 null单测双跑DTO 未注册反射注册类型 hints内网地址可被远程 URL 访问构造内网 URL 请求未启用 SSRF 过滤启用并验证 InetAddressFilter302 重定向绕过过滤跟随重定向测试只校验首次 URL过滤或关闭重定向跟随表达式解析异常抽取表达式批量解析PropertyPath 语法更严修正表达式测试库启动失败测试日志Derby 支持弃用换用受支持数据库本地通过、CI 失败对比 JDK/镜像版本基线不一致统一 toolchain10.3 并存、灰度与回滚三类改动的并存策略不同必须一刀切命名空间javax/jakarta不能混用、Jackson 主版本同一链路不应两套序列化栈可以并存HTTP 客户端实现门面 开关切换、通信协议REST 与 gRPC 分端口/分路径共存必须双跑AOT/native 产物与 JVM 产物用同一套契约测试验证一致性。回滚的前提是配置、数据库脚本、消息契约都能随制品一起回退。特别是 Jackson 3 与消息中间件配合时一旦消息体格式变化回滚应用并不能回滚已写入的消息需要提前准备兼容消费者或版本化 topic。最后再强调一次资料边界本批研究资料中 24 条来源的热度指标全部为 0 或缺失不能用来判断“热点”多篇中文文章自述为二手聚合、互相引用且在 Spring Boot 4 的发布时间上存在三种互相冲突的说法 [3][4][5]。涉及版本号、日期、支持策略、artifact 坐标与配置属性名一律回到 Spring 官方文档与项目 Release Notes 核对后再写入生产代码。参考资料[1] Spring Framework 7.1 Release Notes · spring-projects/spring-framework Wiki · GitHubhttps://github.com/spring-projects/spring-framework/wiki/Spring-Framework-7.1-Release-Notes[2] 《第2课Spring Boot 4.0 核心精讲 微服务前置必备能力》 · CSDNhttps://blog.csdn.net/SearchB/article/details/165009051[3] 《Spring Boot 4.1.0 正式发布正式拥抱 gRPCJava 微服务这次要彻底起飞了》 · CSDNhttps://blog.csdn.net/UL6YX79BL/article/details/162419676[4] 《Spring Boot 4 新特性全解析从上手到生产实战》 · CSDNhttps://blog.csdn.net/qq_42082701/article/details/167495449[5] 《Spring Boot 4 核心升级与云原生实践指南》 · CSDNhttps://blog.csdn.net/weixin_28739079/article/details/164854442说明[2]—[5] 均为中文二手整理材料其中的版本日期、支持策略与具体 API 名称存在未核实之处本文已在相应段落标注版本与基线类结论应以 [1] 及 Spring 官方文档为准。