中间件关键配置该「全量显式声明」还是「只写差异」？默认值到底是安全网还是定时炸弹

【背景】 最近复盘了两起事故，根因居然一致：我们「信任了中间件的默认值」。

• 一起是 Kafka 消费者停机 8 天重启后静默跳了几百万条（社区已有《offsets.retention 默认 7 天》那篇讲得很透）；
• 另一起更隐蔽：HikariCP 升级大版本后，某项与连接回收相关的默认值悄悄变了，我们代码里根本没写这一项，于是行为跟着默认值走了，线上连接回收节奏被改写，pending 线程堆积才暴露。

两起事故的共同点：出问题的配置项，在代码里都是「靠默认值兜底」的。而默认值恰恰是最不可见、最易随版本漂移、最没有 owner 的那部分。

于是我想把方法论层面的争点摆出来：中间件关键配置，到底该全量显式声明，还是只写你关心的差异？

【常见分歧 / 两种做法】

• 做法 A：全量显式声明（belt & braces）。把该组件所有关键项都写进配置，哪怕值和默认一样。
  • 好：行为完全可预期、可 diff、可 code review；升级时一眼看出「我没动它，但它默认变了」；新人可读。
  • 坏：配置冗长、噪音大；中间件版本一升，大量项要跟着 review，升级成本高；容易和官方文档/实际生效值漂移（你以为显式了，其实没显式到真正生效的那一层）。
• 做法 B：只写差异（config-as-diff）。YAML/properties 保持干净，没写的就用默认。
  • 好：干净、升级省心、diff 小、符合「约定优于配置」。
  • 坏：默认值成了隐式契约且无 owner；一旦默认随版本变化，行为漂移无人察觉——上面两起事故都是这个模式。
• 做法 C（我目前更倾向的折中）：分两类治理。对会改变正确性语义的少数关键项（offsets 保留、auto.offset.reset、连接回收/泄漏检测、幂等/重试相关）强制显式声明，并用 lint/CI 卡住「关键项缺失」；对其余「只影响性能/风格」的项，允许走默认。

【我的倾向与理由】 我倾向 C，核心理由是「可维护性 + 可追责」：

1. 不是所有配置都该被同等对待——把「正确性关键项」和「性能偏好项」分层，才能把 review 火力集中在真正会炸的地方，避免 A 方案的升级噪音。
2. 关键项显式化后，就有了 owner：CI 能卡「这项必须声明」，升级时 diff 能立刻暴露默认值漂移，而不是等事故。
3. 但我不主张「全量显式」，因为那会把 80% 的精力花在 20% 不重要的项上，且显式声明本身也会漂移（声明值 ≠ 实际生效值，中间隔着一层版本行为）。
4. 落地需要「显式声明 + 生效值回读校验」一起：光声明不够，最好有手段（启动日志 / actuator / 一个自检脚本）把「你以为的生效值」和「实际生效值」对一遍，否则显式声明只是心理安慰。

【想听大家怎么选】

• 你们团队是 A（全量显式）还是 B（只写差异）？有没有踩过「没写的默认值」导致的事故？
• 如果是 C，你们怎么圈定「正确性关键项」清单？有没有可复用的判定规则（比如「凡涉及 幂等/重试/保留时长/回收/顺序 的项都强制显式」）？
• 有没有在 CI / 启动自检里做「关键项必须显式声明 + 生效值回读」的工具或做法？欢迎贴命令 / 配置。
• 反向观点也欢迎：全量显式是不是过度工程？只写差异 + 好的可观测性是不是就够了？

欢迎对号入座，带上你的场景（组件 + 版本 + 事故/没事故）来聊。