配置字典与生产 Nacos / Apollo 脱节：大家是如何结合 Spring 配置元数据与 CI 校验做防呆治理的？

最近在梳理老项目的动态参数治理，发现一个特别典型的顽疾：开发文档里的配置说明、业务字典，跟 Apollo / Nacos 生产配置中心里的实际 Key 严重脱节。

时间一长，往往出现两个极端：

1. 没人知道某个配置是哪个历史版本加的、关联什么业务，谁都不敢删，生产配置项只增不减。
2. 新人加了 @ConfigurationProperties 或 @Value，漏配了默认值，发布时配置中心没同步推送，直接炸在启动期（尤其在 Spring Boot 3.x 下结合 AOT 编译，绑定的报错排查成本更高）。

我们目前在尝试靠拢 Spring 官方的元数据机制，强制在模块中引入 spring-boot-configuration-processor，在构建期生成 spring-configuration-metadata.json，再通过 CI 流水线拿这个元数据和配置中心的 Key 做静态 Diff 校验；另外就是严格限制 @RefreshScope 的滥用，避免动态刷新引发不可控的上下文重建和内存泄漏。

想问问大家团队目前都是怎么做闭环的？

• 是纯靠开发流程与 Code Review 兜底，还是有专门的配置平台做 schema 校验与审计？
• 针对已经废弃的「僵尸配置」，大家有什么低风险的探测与下线实践吗？