Boot4升级后probes默认开怎么关

Boot4升级后probes默认开怎么关

升到 Spring Boot 4 之后，有一类变化不太会红栈，但运维侧会先发现：没改任何探针配置，/actuator/health下却多出了liveness/readiness两组；K8s 清单若还按 Boot 3「默认关、要显式开」的习惯写，本地 curl 和集群探针路径会对不上。第一反应往往是「谁把 health group 配开了」「是不是加了什么 starter」，翻半天才发现：Boot 4 Migration Guide 把liveness / readiness probes 改成了默认启用。

本文只做这条probes 默认与开关清单：属性全名是什么、旧键迁到哪、怎么关、怎么 curl 验收、管理端口分离时add-additional-paths怎么用、liveness 为什么不要塞外部依赖。同系列里 Flyway starter、Jackson 3 另文已写，见 Boot4升后Flyway迁移不跑怎么改、Boot4升后Jackson3怎么安全迁，本稿不抢主线。

依据以 Spring Boot 4.0 Migration Guide §Liveness and Readiness Probes、Configuration Changelog、application-properties 附录 与 Actuator endpoints §Kubernetes Probes 为准。

一、现象：升完没改配置，探针组突然在了

现场通常长这样：

1. parent / BOM 已经是Spring Boot 4.0+，业务 YAML 里没有手写过 probes 相关键；
2. 本地或预发 curl/actuator/health，多了liveness/readiness组；或直接打/actuator/health/liveness、/actuator/health/readiness有响应；
3. K8s / 运维侧对照旧文档，以为「没开 probes」，却发现路径已经可用——和 Boot 3「要显式开才暴露」的预期对不上。

「能启、无红栈、探针路径突然可用」是值班里常见的表现。根因以 Migration Guide 为准，别先猜成「谁加了 health group」或「Actuator 版本配错」。

还有一种半迁移更隐蔽：YAML 里仍写着 Boot 3 时代的旧键management.health.probes.enabled，以为关了，实际 Boot 4 已迁出该键——新默认仍是开。升级 PR 描述里把「属性是否已是新全名」和「两路径 curl 是否符合预期」拆成两行勾选，比事后对集群探针清单做差分便宜。

值班排障时不妨先问三句：应用是不是已经 Boot 4？YAML 里有没有手写 probes？K8s 探针 URL 是探/actuator/health总览，还是探分拆后的 liveness/readiness？这三句对齐之后，再决定是「接受默认开、改清单」，还是「业务根本不需要探针、应用侧关 false」。顺序反了，容易出现「清单已按关着写、应用仍默认开」或反过来的双端不一致。

二、根因：Migration Guide 明文默认开

Migration Guide §Liveness and Readiness Probes 写明：

The liveness and readiness probes are now enabled by default. This means the health endpoint now exposes thelivenessandreadinessgroups by default.

也就是说：不是「多配一组可选优化」，而是 Boot 4 起默认就把这两组挂到 health 上。不需要时，用属性关掉——同一节给出的键就是management.endpoint.health.probes.enabled。

附录 application-properties 与之一致：management.endpoint.health.probes.enabled说明为 Whether to enable liveness and readiness probes，默认值true。Actuator 文档 §Kubernetes Probes 再次确认：这些 health groups are automatically enabled；可用同一属性 disable。

用一张对照流先钉死「Boot3 显式开 → Boot4 默认开 → 关闭/验收」：

三、属性名迁移：旧键已迁出，关就用新全名

3.1 新键：默认 true，关 = false

关闭探针组写：

management:endpoint:health:probes:enabled:false

或等价的 properties：

management.endpoint.health.probes.enabled=false

附录默认是true；设为false即 Migration Guide 说的「If you do not need those probes, you can disable them」。需要保留默认行为时，可以不写该键——缺省就是开。

3.2 旧键：management.health.probes.enabled已 Removed

Configuration ChangelogRemoved表写明：旧名management.health.probes.enabled的 Replacement 是management.endpoint.health.probes.enabled。

升完若 YAML 里还留着旧键：

# Boot 4 勿再当推荐键（Changelog Removed）# management.health.probes.enabled=false

应改成新全名。可跑 Spring Boot 配置迁移器（properties migrator）对照 Changelog，比肉眼扫 YAML 稳。不要把旧键继续写成「当前推荐写法」。

实践里建议：先在配置树 / 启动 Environment 里确认生效的是management.endpoint.health.probes.enabled，再谈 K8s 探针清单是否改路径。旧键没清干净之前，先改 Deployment 的 probe URL，很容易改出「应用侧其实仍默认开、清单却按关着写」的更难排障状态。

四、怎么验：两条路径 curl

默认management.endpoints.web.base-path=/actuator时，官方暴露的 HTTP 探针路径是：

• /actuator/health/liveness
• /actuator/health/readiness

Actuator 文档原话大意：exposed as separate HTTP Probes by using health groups，并给出上述两条路径。

升 Boot 4、且未关 probes 时，本地可这样验收（端口按你的 server.port 改）：

# 默认开：两条路径应有响应（具体 JSON 字段以现场 Actuator 为准）curl-sS"http://localhost:8080/actuator/health/liveness"curl-sS"http://localhost:8080/actuator/health/readiness"

关掉后再验：

management.endpoint.health.probes.enabled:false

# 设 false 后：liveness / readiness 组按文档不再作为探针组可用# 勿死记某一固定 HTTP 状态码；以你环境实测与文档为准curl-sS-o/dev/null-w"%{http_code}\n""http://localhost:8080/actuator/health/liveness"curl-sS-o/dev/null-w"%{http_code}\n""http://localhost:8080/actuator/health/readiness"

升级 PR 的 DoD 建议拆两行：

• 未关时：两路径有响应（与 K8s probe URL 一致）；
• 明确不需要探针时：management.endpoint.health.probes.enabled=false，且清单不再指向这两组。

若你改过management.endpoints.web.base-path，把路径前缀换成实际 base-path，不要死记/actuator。

验收时建议固定一份「升前 / 升后」对照表：升前（Boot 3）在未显式开启时，分拆探针路径往往不可用或不符合你们旧文档预期；升后未关配置时，两条路径应能打通。把对照结果贴进升级评论，比口头说「探针好像有了」可复核。若环境开了 security 对 Actuator 鉴权，curl 要带上与线上探针相同的认证方式，否则会把「401/403」误判成「probes 没开」——那是安全层问题，不是本文的开关键。

五、边界：add-additional-paths与主端口/livez/readyz

当 Actuator 跑在独立 management 端口时，会出现经典落差：管理口上的 health 还「绿」，主应用端口已经挂了。附录属性：

# 默认 false：不在主端口额外挂探针路径 management.endpoint.health.probes.add-additional-paths=false

设为true后，官方文档说明：会在主服务器端口额外暴露——liveness组对应/livez，readiness组对应/readyz（这是官方默认附加路径名；也可按 group 的 additional-path 自定义，点到为止）。

management:endpoint:health:probes:enabled:trueadd-additional-paths:trueserver:port:9090# 示意：management 独立端口时，按你项目实际配置

# add-additional-paths=true 时：主端口（示意 8080）上的附加路径curl-sS"http://localhost:8080/livez"curl-sS"http://localhost:8080/readyz"

实践上：默认是 false；只有「管理口与主口分离、且希望 K8s 探主口」时才打开。不要臆造其他默认路径名，也不要把它和probes.enabled=false混成同一开关。

六、liveness 勿塞外部依赖

Actuator §Checking External State With Kubernetes Probes 写明：

The “liveness” probe should not depend on health checks for external systems.

外部（DB、远端 HTTP、消息中间件）挂了若进liveness，K8s 可能整批重启实例，反而放大故障面。readiness 是否包含外部检查，由业务自己判断——可以更严，但那是产品语义，不是「默认帮你塞进探针组」。

同一节还写：By default, Spring Boot does not add other health indicators to these groups。也就是说，Boot默认不会把磁盘、DB 等其它 indicator 自动加进liveness/readiness两组；若你自定义往里塞，先确认没有违反上面的 liveness 警告。

一句收束即可：关不关 probes 是开关问题；往 liveness 里塞什么，是稳定性问题——两者别搅在同一个「先改 YAML 碰运气」的 PR 里。

若团队之前在 Boot 3 手工配过自定义 health group，升级后先核对：自定义组有没有被误当成「官方 liveness/readiness 默认组」一起改。默认两组的边界以 Actuator 文档为准；自定义 group 的成员列表仍是你们自己的配置，不在「probes.enabled」这一键里自动清空或自动塞入。

七、常见问答

Q1：Spring Boot 4 为什么默认打开 liveness/readiness？
A：Migration Guide 明文 probes are now enabled by default，health 默认暴露这两组。动机侧官方按 Kubernetes 探针惯例默认打开；成稿以「默认开、不需要可关」为准，勿编造未给出的产品数字。

Q2：用哪个属性关掉 probes？
A：全名management.endpoint.health.probes.enabled，设false。附录默认true。

Q3：旧的management.health.probes.enabled还能用吗？
A：Changelog 已Removed，Replacement 是新全名。升完请改键；不要继续当推荐写法。

Q4：升 Boot4 后怎么验证 probes 路径可用？
A：未关时 curl/actuator/health/liveness与/actuator/health/readiness（相对默认 base-path）；关 false 后组按文档不可用。管理口分离且需要探主口时，再考虑add-additional-paths=true后的/livez/readyz。

Q5：关了 probes 是否等于关了整个/actuator/health？
A：不是。关的是 liveness/readiness探针组；不要和「禁用整个 health endpoint」混为一谈。具体还暴露哪些 group，以你当前management.endpoint.health.*配置为准。

八、小结

Boot4 上 probes 这条线，可压成五步：

1. 认默认：Migration Guide — probesenabled by default，health 默认暴露liveness/readiness。
2. 改键名：旧management.health.probes.enabled已 Removed → 新management.endpoint.health.probes.enabled（默认true）。
3. 要关就写 false：不需要探针时显式关闭；需要默认行为可不写该键。
4. 验收路径：curl/actuator/health/liveness与/readiness；管理口分离时按需add-additional-paths→ 主端口/livez/readyz。
5. 稳住 liveness：勿把 DB 等外部依赖塞进 liveness；Boot 默认也不把其它 indicator 加进这两组。

把「属性是否已是新全名、两路径是否与 K8s 清单一致」写进升级 DoD，比事后在集群事件里猜「探针突然有/无」便宜。半迁移（旧键残留，或只改清单不改应用配置）优先当缺陷修。

落地时把「配置键与默认」和「curl / 集群探针 URL」拆两次验收：一次看 Environment 里生效的属性全名，一次再打两路径——混在同一巨大 PR 里，容易只盯暴露清单、漏掉残留的旧management.health.probes.enabled。同系列（Flyway、Jackson 3）建议拆开合入。本稿只负责「默认开 / 怎么关 / 怎么验」三条可勾选。

若还在用 Boot 3「显式打开 probes」手册，升 4 后先改口径：默认已是开，清单写的是「要不要关」和「路径是否仍是 /actuator/health/liveness|readiness」，而不是「要不要加一段开启配置」。

---