Spring Boot 4.2-M2 带着新基线来了：这次卡住升级的不是代码，是配置

升级到 Spring Boot 4 的第一个下午，最常见的报错长这样：应用起不来，日志里只有一句——某个配置属性绑定失败，原因是找不到对应的类。Java 代码一行没动，卡住的是 application.yml 里的一个键。

这类问题在 Boot 4 的迁移里出现得非常密集，而且它们几乎都不是"代码问题"。

Spring Boot 4.2.0-M2 在 9 月 25 日发布，官方说包含 141 项改进（含文档、依赖升级与缺陷修复）；9 月 24 日，Spring Cloud 2026.0.0-M1 发布，代号 Paddington，基于 Boot 4.2.0-M2，15 个核心模块一起进到 5.1.0-M1。4.2 的正式版按目前的里程碑节奏，预计在 11 月。

第一笔账：基线往前挪了一格

Boot 4.0 开始，Java 17 成为最低基线，Java 8 及更低的支持被彻底拿掉。这在迁移里最容易被低估——不是编译不过就改，而是某个几年没人碰的旧模块可能连 Java 11 都过不去，整条升级链就停在那里。

4.2 是第一条把目标指向 Java 27 的线。对生产系统来说倒不用慌：Java 的节奏是两年一个 LTS（8/11/17/21/25），Boot 4.x 仍然能跑在 Java 17 和 21 上。

官方给的建议也很明确：先升到 3.5，把弃用告警清干净，再谈升 4.0。这一步省不掉，因为迁移指南本身是以 3.5 为基线写的。

第二笔账：配置绑定变严了

Boot 4 里配置属性的绑定规则更严格。表现就是开头那种报错：键写了、值也没错，但绑定时缺类或者类型对不上，应用直接起不来。

以前这类问题可能被静默忽略。现在它会拦在启动阶段——这本身是好事，只是它把过去几年攒下来的、写得不严谨的配置一次性摊开了。一个跑了五年的项目，配置文件里的历史遗留键，数量通常比业务代码还多。

第三笔账：序列化层换了默认

Boot 4 的默认 JSON 库换成了 Jackson 3。Jackson 2 还在，但已经是弃用状态。

这不是升个版本号的事。Jackson 3 有自己的包名与模块结构，任何直接引用 Jackson 类型的地方——自定义序列化器、日期格式配置、全局 ObjectMapper 的定制——都要跟着动。而这类代码通常散在各个模块里，不集中。

第四笔账：安全和可观测进了发版节奏

这一轮两个里程碑里最实的新特性都在这两块：SSL bundles 开始覆盖 LDAP 连接，内嵌 LDAP 服务支持 LDAPS；可观测侧开始支持 OpenTelemetry 的语义约定，并把 OTLP 的端点、请求头、压缩这些配置收成一组通用属性，traces、metrics、logs 共用一套。

Spring Cloud Paddington 那边有个容易被忽略的改动：Gateway 处理来自不可信代理的转发请求头时收紧了规则。如果你的服务在多层代理后面，客户端 IP 和协议的取值可能跟以前不一样——这类改动不会报错，只会静默改变行为。

还要提醒一句支持周期：Boot 3.5 的开源支持已经在 2026-06-30 到期，4.0.x 的开源支持按公开的支持矩阵到 2026-12-31，4.1.x 到 2027-07-31。所以"先不升"这个选项，是有期限的。

升级要有一张说得清的施工图

上面这四笔账有个共同点：它们都不是"改代码"能解决的，真正要回答的是——我们当初为什么选这些版本、这些配置。

飞算JavaAI 的智能会话里，/前后端设计 会把技术栈的选择单独产出一份"技术栈决策"文档，和数据库设计、接口设计、技术需求覆盖、后端设计规范基线一起落到项目的 docs 目录；上游的 /需求分析 会先把需求与业务设计落成文档，需求边界模糊时先向人提问澄清，不直接开写。

因果也很直接：升级真正卡住人的地方，是"原来为什么这么定"没有记录。哪天谁把序列化库换了、为什么这份配置里有三个看起来重复的键，翻提交记录翻不出来。技术栈决策落成文档之后，升级时手里就有一份比对依据——哪些是刻意选的、哪些是历史遗留，一眼能分。清单能列出来，活才有边界。

边界也要说清：文档不替代兼容性测试，也不会自动判断某个弃用 API 的替代方案是否等价。它解决的是"升级前不知道该动哪里"，不是"升级不用测"。

一张可以照着过的升级清单

把四笔账折成动作，大概是这样一份清单。

先做基线评估：确认生产上跑的 JDK 版本，把升不上去的模块单独列出来。Boot 4 要求 Java 17 起，这些模块决定了整体能不能动。

再清弃用告警：官方建议先升到 3.5 把弃用告警清零，因为迁移指南以 3.5 为基线。这一步没法跳过去。

然后审配置：把所有 application.yml、.properties 里的键过一遍，对照 Boot 4 的属性表，重点看那些以前能被容忍、现在会拦住启动的项。

接着扫序列化：搜一遍代码里对 Jackson 的直接引用，尤其是自定义序列化器、日期格式、ObjectMapper 定制，评估迁移面。

最后排回归：如果服务在多层代理后面，Gateway 对转发头的处理规则收紧了，客户端 IP 和协议的取值可能变化。这类改动不会报错，只能靠回归用例发现。

这份清单有个特点：五步里只有第一步和第三步会真的改代码，其余三步都是"先把情况摸清楚"。这也解释了为什么很多团队升级时觉得"比想象中麻烦"——麻烦不来自改动量，来自事先不知道要改哪里。

什么时候可以等一等

现在这个时间点，要不要立刻动 4.2？我的判断是：4.2-M2 还是里程碑版本，正式版按目前节奏预计 11 月，生产系统不必抢在前面。真正值得马上做的，是把上面那份清单先过一遍——它的结论不依赖 4.2 是否 GA。

还有一个更实际的判断依据：升级的收益要在"你的项目真的用到了新能力"时才兑现。SSL bundles 支持 LDAP、OTel 语义约定这些改动对用到的人价值很高，对没用到的人只是版本号变化。所以评估顺序应该是先看清单里有多少项跟自己相关，再定要不要动。

反过来说，如果有项目还停在 3.5 之前，优先级要提前。3.5 的开源支持已在 2026-06-30 到期，4.0.x 按公开矩阵到 2026-12-31。支持周期不等人，它和你的排期无关。

写在最后

Spring Boot 的版本节奏这几年一直很稳，稳到容易被忽略。真正让人在升级上翻车的，从来不是新版本的特性，而是旧项目里那些没人记得为什么这么写的配置。

版本升级考的是回看能力：你对自己项目里那些决定的了解，够不够支撑一次迁移。这份了解如果只存在某个人的记忆里，它迟早会随着人员流动一起消失。