Spring Cloud 2026.0.0-M1 Paddington：升级前必看的几处变化

谁该关心这篇

如果你的服务已经（或计划）挂在 Spring Cloud 列车上——尤其是 Gateway 前面还有一层反向代理、Config Server 要对接 Azure DevOps、或者 Circuit Breaker / OpenFeign / Vault 需要跟 Boot 4.2 里程碑对齐——那么 2026.0.0-M1（Paddington） 值得先读官方 Notable Changes，再决定要不要在预览环境动手。

站内「每日快讯」和 Boot 4.2.0-M2 专稿已经点名过 Paddington。这篇不复述 Boot 侧的 LDAPS / OTLP，只把 Cloud 列车里「升级前会踩坑」的几处变化摊开成可执行清单：Gateway 转发头信任、Config 新能力、以及 BOM 依赖对齐。

官方公告由 Ryan Baxter 于 2026-09-24 发布：基于 Spring Boot 4.2.0-M2，BOM 为 spring-cloud-dependencies:2026.0.0-M1，产物在 Spring milestone 仓库。GitHub tag v2026.0.0-M1 标记为 pre-release。节奏背景上，Michael Minella 在《Releasing Spring for Modern Challenges》里说明：生态改成每月「Patch Thursday」，首次正式补丁日定在 2026-10-22；九月这一槽以里程碑为主、为十一月功能版铺路——所以 M1 适合验证，不适合直接当生产基线。

BOM 与 milestone 仓库怎么引

Maven 用 dependencyManagement 导入 BOM（摘自官方公告示例，可按需删减 starter）：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-dependencies</artifactId>
      <version>2026.0.0-M1</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<repositories>
  <repository>
    <id>spring-milestones</id>
    <name>Spring Milestones</name>
    <url>https://repo.spring.io/milestone</url>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </repository>
</repositories>

Gradle 同样需要把 https://repo.spring.io/milestone 加进 repositories，并用 dependency-management 插件导入：

dependencyManagement {
  imports {
    mavenBom 'org.springframework.cloud:spring-cloud-dependencies:2026.0.0-M1'
  }
}

repositories {
  mavenCentral()
  maven { url 'https://repo.spring.io/milestone' }
}

实操时再确认三件事：

1. 这是 milestone，不要和 Maven Central 上的正式 Cloud 列车混用；公司 Nexus / Artifactory 若没代理 repo.spring.io/milestone，CI 会解析失败。
2. 列车与 Boot 绑定是 4.2.0-M2。单独升 Cloud、却把 Boot 留在更早里程碑或正式版，官方未保证兼容——请成套对齐。
3. 父 POM 里若还有旧的 spring-cloud-dependencies 或强制锁定 Feign / Resilience4J / Spring Vault 的版本，先解掉再依赖 BOM，否则「看起来升了列车、实际还是旧传递依赖」。

Notable Changes：对线上意味着什么

下面按官方公告条目说明影响面。具体类名、配置键以各模块 release notes / issue 为准；正文不编造未在公告中给出的 API。

Circuit Breaker → Resilience4J 2.4.0

spring-cloud-circuitbreaker 升到 Resilience4J 2.4.0（公告引用 #301）。对业务侧通常是传递依赖升级：如果你显式锁定了旧版 Resilience4J，或写了依赖其内部 API 的自定义装饰器，先在预览环境跑通断路、限流与指标导出。默认 starter 用法多数只需做回归，重点看超时、fallback 与监控面板数值是否漂移。若你们用 Micrometer 看 resilience4j.* 指标，升级后对比一次看板基线，避免把依赖升级误判成业务故障率变化。

Config：HTTP property-path notifier，以及 Azure DevOps workload identity

Config 两处增量（#3279、#3272）：

1. HTTP property-path notifier：适合用 HTTP 回调驱动配置刷新、且希望按 property path 粒度通知的场景。若你已有自定义 webhook / Spring Cloud Bus 刷新链路，升级后对照 Config 5.1.0-M1 文档确认 notifier 如何注册与触发，避免与现有刷新通道重复打满实例。
2. Azure DevOps workload identity：在 Azure 上跑 Config、并希望用 workload identity 访问 DevOps 后端时，这是官方新增支撑点。本地能验证「能否启动并拉到配置」；真实身份联邦、权限范围与密钥轮换仍需在对应云环境实测，无法在开发机上完全代替。

如果你既不用 HTTP notifier 也不碰 Azure DevOps，这两项可以记在变更单里「已知、暂不适用」，把测试时间让给 Gateway 与依赖对齐。

Gateway：Retry 迁到 Framework Core；untrusted proxies 的 forwarded headers

Gateway 两条都偏「线上行为」，建议网关负责人亲自回归。

1. Retry 从 Reactor Addons 迁到 Framework Core Retry（#4290）。底层实现换了家。如果你依赖旧 Reactor Addons Retry 的扩展点，或自定义了与 Gateway Retry filter 耦合的代码，升级后优先回归三类用例：超时后是否按预期重试、非幂等写操作会不会被误重试、退避 / 最大次数是否仍符合现网策略。配置属性名是否变更，请以 Gateway 5.1.0-M1 文档为准，本文不臆造键名。
2. Fix forwarded headers for untrusted proxies（#4271，关联 #4267）：此前当远端地址不在可信代理列表时，ForwardedHeadersFilter / XForwardedHeadersFilter 会清掉已有的 Forwarded / X-Forwarded-* 后直接返回，不会再用真实请求信息生成新的转发头。修复后：来自不可信代理的头仍会被丢弃（安全边界不变），但过滤器会继续处理，并基于实际 remote address 与请求细节重新生成转发头。

这对「网关前面还有 Nginx / 云负载均衡 / Ingress，但信任列表漏配、或某些环境故意不信任」的拓扑尤其敏感：下游看到的 client IP、scheme、host 可能从「空 / 旧头残留」变成「按真实连接重写」。升级后请在预览环境至少核对：

• 访问日志、风控与限流键使用的 client IP；
• 生成绝对链接、OAuth / OIDC redirect、Cookie Secure / HSTS 时依赖的 scheme 与 host；
• 多级代理下 X-Forwarded-* 是否仍符合你的信任模型（只信任真正的边缘代理，而不是内网任意跳）。

可信代理列表本身怎么配，仍以你当前 Gateway / Boot 文档为准。本修复改变的是「判定为不信任时」头处理是否完整，而不是鼓励你把所有上游都标成 trusted。若现网曾靠「清头后碰巧为空」掩盖错误配置，M1 上可能会提前暴露——把它当成修复，而不是回归失败。

OpenFeign → Feign 13.14

OpenFeign 升到 Feign 13.14（#1404）。重点回归：编码器 / 解码器、连接与读超时、重试，以及与负载均衡、熔断的组合。若项目里直接依赖 io.github.openfeign:feign-* 并锁了旧版本，先放开让 BOM 托管，再看编译与契约测试。有自定义 Contract / Capability 的团队，额外跑一轮与目标服务的集成测试。

Vault → Spring Vault 4.1.0

spring-cloud-vault 对齐 Spring Vault 4.1.0。密钥后端、AppRole / Kubernetes auth、以及启动时拉取 secret 的路径，建议在非生产 Vault 命名空间做一次完整启动与轮换演练。认证方式与后端细节以 Spring Vault 4.1 与 Cloud Vault 模块说明为准，升级前先读对应 release notes，再改生产策略。

官方模块版本表（对照用）

公告给出的 2026.0.0-M1 模块版本如下（各模块 Issues 链接见官方公告原文）：

核对依赖树时，盯住这些坐标是否被第三方 BOM 或公司父 POM 盖掉。GitHub Release 页的模块列表与上表一致，亦可作交叉检查。

M1 预发布风险（写进变更单）

• 不是 GA：milestone + GitHub pre-release，API 与默认行为仍可能在后续里程碑调整。
• 依赖链更长：Cloud → Boot 4.2.0-M2 → 对应 Framework 里程碑，任一环用正式版「半升级」都容易出现难查的 NoSuchMethodError 或配置绑定差异。
• Gateway 转发头：行为修复可能让「以前凑巧能用」的错误信任配置暴露出来——这是好事，但需要明确的测试窗口与回滚方案。
• 安全与合规：预览版不建议进入生产变更窗口；跟 Patch Thursday（2026-10-22 起）的正式补丁节奏分开规划。九月槽位本身就是里程碑列车，别把它当成补丁日产物。

升级检查清单

1. 父 POM / BOM 改为 spring-cloud-dependencies:2026.0.0-M1，并确认构建机能访问 https://repo.spring.io/milestone。
2. Boot 对齐 4.2.0-M2（或官方后续明确兼容的同列车版本）；禁止只升 Cloud。
3. 用 mvn dependency:tree（或 Gradle 等价命令）确认 Resilience4J、Feign、Spring Vault 版本来自本列车，而不是被强制覆盖。
4. Gateway：准备「可信代理 / 不可信代理」两组对比请求，断言下游看到的 IP、scheme、host；同时回归带 Retry 的路由。
5. Config：若使用 Azure DevOps 或 HTTP 刷新，分别验证拉配置成功，以及 notifier 触发次数是否符合预期。
6. OpenFeign 契约测试与 Vault 启动拉密各跑一遍；有熔断的调用链做一次故障注入。
7. 将结果写进变更单；生产升列车等待 GA 或正式补丁日，而不是把 M1 当基线。

参考链接

• Spring Cloud 2026.0.0-M1 (Paddington) 公告（Ryan Baxter，2026-09-24）
• GitHub Release tag v2026.0.0-M1
• Gateway #4271：untrusted proxies 的 forwarded headers
• Releasing Spring for Modern Challenges（Michael Minella，节奏背景）