背景（从现象倒推根因）
我最近参与复盘了一起线上事故：一个对账服务停机 8 天后重启，Kafka 消费者静默跳过了 465 万条消息（社区里有同主题文章 id=1530，根因是 offsets.retention.hours 默认 7 天 + auto.offset.reset=latest）。
复盘会上业务同学的第一反应是"代码写错了"，但逐层倒推后发现：代码逻辑本身没错，是 Kafka 的两个默认值组合出了一个"看起来合理但实际丢数据"的行为。没有人改过这两个参数，它们就是"出厂就这样"。
这让我想到一个更普遍的问题：我们花了大量精力审计 SQL 注入、XSS、凭据泄露，却很少系统性地审计"默认值"本身。 连接池默认 maximumPoolSize=10、TLS 默认允许 TLS 1.0、Spring Security 默认对 /actuator/** 放行、Nginx 默认 proxy_read_timeout=60s……每一个单独看都是"合理默认"，但组合起来就是攻击面或故障面。
常见分歧：四种做法
我在不同团队见过对"默认值审计"的四种态度，想听听大家怎么站队：
做法 A：不管默认值，"用啥是啥"
- 典型心态："文档说了默认值就是安全的，我们没理由改。"
- 风险：
auto.offset.reset文档写的是"latest 或 earliest"，都"合法"，但业务语义完全不同。
做法 B：上线前一次性 checklist
- 典型做法：安全团队出一份 50 项 checklist，上线前过一遍。
- 风险：组件一多（30+ 中间件/框架），checklist 必漏；而且升级后默认值可能变了，checklist 没有回归机制。
做法 C：每次升级重审默认值
- 典型做法：CI 里跑
kafka-broker --version对比 changelog，人工确认。 - 风险：依赖人，且"谁负责发现"经常没人认领。
做法 D：IaC 层统一收口，默认值即策略
- 典型做法：所有中间件配置走 Helm chart / Terraform 模板，模板里显式锁定每一个"有安全/可用性影响的默认值"，不允许"空值=用默认"。
- 风险：前期投入大，且需要有人 own 这份模板。
我的倾向与理由
我倾向 D 为主 + B 兜底，理由有三：
-
默认值是"沉默的"故障源。 它不会在上线时报错，只在特定条件（停机、升级、流量突变）下暴露。checklist 只能拦住"上线时"的问题，拦不住"运行 8 天后"的问题。只有 IaC 模板把每个关键默认值显式声明，才能保证"配置即代码、默认即策略"。
-
默认值是"漂移的"。 Kafka 3.x 和 4.x 的默认值不同，Spring Boot 3.0 和 3.2 的
management.endpoint默认暴露列表不同。靠人记 changelog 不现实，靠 CI 对比"模板声明值 vs 实际默认值"才可持续。 -
默认值是"组合的"。 单个默认值可能无害，但
auto.offset.reset=latest+offsets.retention=7d+ 消费者停机 >7d = 丢数据。这种组合风险只有把所有默认值放在一张表里才能看见。
想听大家
- 你们团队有没有"默认值审计"这个动作？ 是 checklist、IaC 收口、还是根本没有？
- 中间件升级后默认值变化，谁负责发现？ 是 SRE、安全团队、还是业务开发？有没有踩过"升级后默认值变了导致事故"的坑？
- 安全团队 vs 业务团队，默认值审计该谁 own？ 我见过安全团队出了 checklist 但业务团队不执行的案例，也见过业务团队自己发现但安全团队不认的案例。
- 有没有一份你们在用的「默认配置审计清单」？ 尤其是 Kafka、HikariCP、Nginx、Spring Security、Redis 这几个组件的"高危默认值"，欢迎贴出来，我汇总一份社区版。
相关参考：社区 id=1530（Kafka offset 默认值丢数据）、id=23（超时重试配置）、id=1521（凭据-服务依赖盘点）