中间件配置到底是"代码即配置"还是"配置中心为王"？

背景 最近帮几个团队做中间件治理复盘（消息队列、RPC 框架、缓存客户端这类自研组件），翻了一圈配置链路后发现一个反复出现的分裂：同一套中间件，A 团队 90% 参数写在代码仓库的 yaml 里走 GitOps 发布；B 团队几乎全部参数挂在配置中心，日常调参不动代码；C 团队是"敏感参数走 KMS/Vault，运行参数走配置中心，行为开关走代码默认值"的三段式。三种做法都能跑，但半年后各自的事故画像完全不同——A 团队从没出过"参数改错没回滚"的事故，但每次调参都要走一轮发布；B 团队调参极快，却出过两次"配置中心抖动导致全量参数回落到默认值"的故障；C 团队最稳，但新同学上手成本最高。

常见的几种分歧

1. 改参是否需要走代码评审？ 派系一认为参数就是代码的一部分，必须 diff、必须 review、必须可回滚；派系二认为参数是运维面，走发布流程太慢，值班期改不了参数等于没兜底。
2. 配置中心挂了，中间件该用"最后一次成功值"还是"编译期默认值"？ 这直接决定了配置中心是"唯一事实源"还是"覆盖层"，但很多 SDK 的实现是后者的裸奔版——fallback 直接落到代码默认值，等于配置中心一抖动，全量参数瞬间回到出厂设置。
3. 默认值该保守还是激进？ 这其实和配置管理是同一个问题的两面：如果你相信所有用户都会认真配参，默认值可以激进；如果相信大部分用户不会配，默认值必须保守，甚至要对"没配"这个状态做防御。
4. 热生效的边界在哪？ 连接池大小、超时、批量窗口这些参数热改，中间态是怎么过的？我见过把 maxConnections 从 50 热改到 500 直接打爆下游的案例，热生效本身也需要"变更速率限制"。

我的倾向与理由 我站"代码即配置"的派，但不是纯派。我的原则是三条：

• 参数默认值必须写在代码里，且必须是"生产可跑"的保守值，配置中心只是覆盖层，不是事实源。这样配置中心挂了，系统退化的幅度是有界且可预期的。
• 所有参数变更（包括配置中心的）必须留痕，谁在什么时间把什么参数从多少改到多少，要能像 git log 一样查。无留痕的配置中心等于没有配置中心。
• 热生效的参数必须显式声明，且要有"变更速率"约束，不允许一步到位。

理由很朴素：中间件是基础设施，它的参数错误是乘法放大的——一个连接池参数配错，影响的是所有接入方。基础设施的变更流程应该比业务代码更重，而不是更轻。

想听大家说

• 你们团队中间件参数到底放哪？代码、配置中心、环境变量，比例大概多少？
• 配置中心不可用时，你们的 SDK 是回落到"最后一次成功值"还是"代码默认值"？出过什么事？
• 参数热生效，你们有没有遇到过"改参本身就是故障"的案例？怎么防的？
• 有没有人做过"参数变更留痕 + 自动回滚"这套东西？踩了什么坑？

欢迎带具体中间件（Kafka 客户端、自研 RPC、缓存 SDK 都行）和具体参数来聊，纯观点输出容易流于空谈，带场景的讨论才有价值。