"中间件默认值"该被当成起点还是契约？你们有没有一份"默认值审计清单"？

【背景】 做了 10 年中间件研发，复盘历次事故，发现有一类根因特别常见——"默认值没改"。举几个（脱敏）例子：

• Kafka producer 用默认 acks=1，一次 broker 抖动，几十万条消息"已 ack 实则未落盘"——不是 broker 丢了，是 leader 还没同步给 follower 就被确认了。
• HikariCP 用默认 maximumPoolSize=10，QPS 从 200 涨到 800，开始大面积 ConnectionTimeoutException。
• MySQL 备库默认 innodb_flush_log_at_trx_commit=2，宕机 3 分钟，回滚了 10 分钟的事务。

但反过来，我也见过"改默认值改出问题"的：把 Kafka acks 改成 all，吞吐直接掉 40%；把 Redis 客户端 timeout 调太短，一次正常 Full GC 就触发了下游超时雪崩。

所以这个问题一直卡在我脑子里："中间件默认值"在你们团队到底被当成什么——一个"起点"，还是一个"契约"？

【常见分歧】 我在不同团队见过三种阵营：

1. 都改派：默认值是为"最通用场景"调的，你的业务一定特殊，必须显式覆盖。
2. 默认派：上游默认值已经过大量场景验证，乱改有副作用，"出问题再改"。
3. 契约派：默认值是一份"你改了就要懂它内部机制"的契约——不懂就别动。

【我的倾向与理由】 我倾向 "选择性改 + 改动可见"：

• 有一小撮"必改项"：连接池大小、超时、buffer、GC 参数、acks 级别——这些默认值几乎不可能直接匹配生产，建议一律显式配置。
• 其他配置项可以保留默认，但要"可见"：把配置写在代码/配置中心里，而不是藏在启动脚本或环境变量里；并且要有一句话注释说明"为什么用默认值"。
• 改任何默认值之前，得能讲清一个机制：比如改 Kafka acks，你得知道 follower 同步路径上会发生什么；讲不清就别改。

打个比方：默认值就像汽车的"出厂设置"——大多数时候直接开没问题，但你要跑山路，就得调传动比；乱调，反而可能把发动机搞报废。

【想听大家】

1. 你们公司有没有一份"核心中间件默认值审计清单"？维护节奏是怎样的（新组件接入时过一遍？还是季度复盘）？
2. 有没有被"默认值没改"坑过的具体案例？根因是什么、事后怎么补的？
3. 有没有反过来"改了默认值反而出问题"的案例？
4. 对新人，你们会不会要求"改配置前必须先讲清机制"？这条规则是怎么落地的——Code Review 卡点？还是文档？