Nacos 配置中心推送与 K8s 滚动发布先后错配，导致新旧代码读到错版配置，怎么兜底？

【背景】 我们用 Nacos 2.2 做配置中心，应用是 Spring Boot 3 + K8s（1.28），一次发布涉及"改代码 + 改配置"两件事。团队约定：先在 Nacos 控制台把新配置（比如新增的开关、改了的超时值）推上去，再执行 kubectl 滚动发布。配置项里有 feature.x.enabled、db.timeoutMs、ratelimit.qps 三类，代码里用 @RefreshScope 监听变更。

【现象】 最近两次发布都出现了"配置领先于代码"的错配窗口：

1. 老版本 Pod 还活着，但 @RefreshScope 已经收到了新配置（多了一个它不认识的字段、一个改小了的值），老代码按旧逻辑读到新值，触发了一次限流阈值被误调低、接口被自家网关打挂的故障；
2. 新版本 Pod 启动时，本地 snapshot 还是旧配置（Nacos client 的 failover 目录），启动期读到旧值，跑了几秒才拉到新值，期间行为不一致。

【已尝试的排查与结果】

• 把发布顺序反过来（先发代码、再推配置）：解决不了问题 2，新代码启动期读到旧配置的时间窗还在；
• 在代码里加"配置版本号 + 代码版本"的启动校验，版本不匹配就 fail-fast：能挡住问题 2，但问题 1 的老 Pod 收推送这件事没解决；
• 把 @RefreshScope 改成只读启动期快照、运行期不热更：稳了，但失去了在线调参能力，团队不接受；
• 用 K8s 的 preStop 钩子在 Pod 下线前主动 unsubscribe：理论上能缩小窗口，但没系统评估过 unsubscribe 与 Nacos 长连接的竞态。

【期望得到的答案形态】

1. 你们团队在"代码 + 配置"耦合发布时，有没有一套可复现的发布编排（工具、步骤、卡点）？最好能贴命令或脚本骨架；
2. 针对"老代码收到新配置"和"新代码读到旧快照"这两个窗口，各自的兜底方案是什么？是按配置项做兼容性约束、按代码版本做配置分组、还是别的？
3. 有没有人把配置项的"代码兼容范围"写成显式元数据（比如 supportedBy >= v2.3），在推送侧拦截？