Spring Boot 3.5 继续把结构化日志往生产可用方向推进，ECS、GELF、Logstash 这些格式终于不用每个项目手搓一套 logback 配置。但我见过不少团队切成 JSON 后，排障并没有更快，只是把文本噪音换成了 JSON 噪音。
本文适用于 Java 17/21、Spring Boot 3.4/3.5、Logback/Log4j2、Actuator/Micrometer 体系。Spring 官方文档和 release notes 只用于核对 structured logging、ECS/GELF/Logstash 支持和观测能力，正文按生产改造复盘写。
业务场景：出了错，却只能搜到一堆漂亮 JSON
一次支付回调超时，日志平台里有 traceId、spanId、orderId，看起来字段很多。真正排查时才发现，不同服务字段名一会儿叫 orderId，一会儿叫 order_id，还有的放在 message 里。JSON 是结构化了，团队约定没有结构化。
更麻烦的是异常堆栈全量进索引，日志量涨了三倍，告警规则还在匹配旧文本。上线第一天大家都觉得高级，第二天开始嫌日志平台慢。
先定字段契约，再谈格式
我会先定一张字段表：时间、级别、logger、traceId、spanId、service、environment、bizId、errorCode、exceptionType、message。字段少一点没关系，关键是跨服务一致、类型稳定、能被索引。
Spring Boot 的结构化日志格式解决的是输出形态，业务字段治理还得自己做。比如订单系统就明确只放 orderId，不放完整用户资料；支付系统只放支付单号，不把回调原文整段塞进日志。
问题复现：MDC 没清理，日志串味
结构化日志常见事故不是配置错，而是上下文生命周期错。MDC 放进去以后没有清理，异步线程里上下文断掉，或者线程复用时把上一个请求的 orderId 打到下一条日志里。
上线检查清单
- 确认分类和主题都是 Java/Spring Boot，不把日志平台部署问题写成主线。
- 字段名是否跨服务一致，是否有索引模板和类型约束。
- MDC 是否在 finally 或 try-with-resources 中清理。
- 异常日志是否脱敏，是否避免打印完整请求体和 token。
- 日志体积、索引成本、采样策略是否经过压测。
- 告警规则是否从文本匹配迁移到字段查询。
我的经验
结构化日志不是为了让日志看起来像一份 JSON 简历，而是让故障检索稳定、链路串联清楚、告警规则少一点玄学。先治理字段，再切格式；先灰度成本，再全量推广。
