各位好，我是沈墨白，做了 15 年技术产品，最近半年把团队里所有「用户不改也能跑、但一改就出事」的默认参数翻了一遍，越想越觉得这件事值得单独拉出来吵一架。热榜上连接池（id=18）和超时重试（id=23）两篇我都看完了，写得很扎实，但我想把问题再往前推一步：这些参数的出厂默认值，到底该按谁的标准定？
背景：默认值是产品的一部分，只是没人给它写 PRD
我统计了团队过去 12 个月的 23 起线上事故，其中 9 起（39%）的根因可以追溯到「某个默认参数在用户场景下不合适，而用户根本没改过」。举 3 个我印象最深的：
- 超时 30s 的默认值坑了批处理用户：我们一个内部 SDK 默认 timeout=30s，交互场景没问题；一个做数据回刷的租户拿它跑 200 万行任务，30s 必超时，超时后又触发默认的重试 ×3——结果一个任务变成 4 倍写入。事故复盘时第一句话是「用户为什么不改超时」，这句话本身就很产品。
- 连接池默认 10 坑了多租户：单实例 10 连接很安全，但一个用户在同一进程里挂了 40 个租户 client，就是 400 连接直怼数据库，buffer pool 直接被冲掉。
- 重试默认开启坑了非幂等接口：网络抖动 2 次，用户的「扣库存」接口被调了 3 遍。
常见分歧：我观察到的三种流派
- 流派 A「保守安全派」：默认值向最坏情况看齐——超时短一点（200ms 而不是 3s）、重试默认关、连接池给个 5。理由是「宁可用户投诉慢，不能替他背数据事故的锅」。
- 流派 B「激进好用派」：默认值向 80% 用户看齐——超时给够（3s）、重试默认 2 次、连接池给 10。理由是「默认值就是给不会读文档的人用的，让他开箱能跑通比什么都重要」。
- 流派 C「场景分治派」：同一个 SDK 按 profile 给不同默认（interactive / batch / embedded），默认值本身做成可发现的配置树。代价是复杂度翻倍，文档得跟着重写。
我的倾向：默认值要为「承担后果的人」负责，而不是为「写代码的人」负责
我的原则可以压缩成三条，附具体数字：
- 谁承担失败后果，默认值就向谁保守。超时默认值不该是「下游 P99 + 余量」，而该是「调用方用户能感知卡顿的上限」。对 C 端接口我会定 800ms 而不是 3s——因为超时的后果是用户盯着转圈，这个后果用户自己承担，他就有权要求默认保守。
- 默认开启的每个动作，必须幂等，否则默认关。这条没有商量余地：重试、自动建表、自动迁移 schema，这三类我全默认关，开需要显式配置项（名字里带 enable_ 前缀，逼用户读文档）。
- 默认值要有「自毁机制」：保守到一定程度就该报错而不是静默降级。比如连接池等待超过 200ms 直接抛错并带上「你的池子可能是 N 个 client × M 个连接」的提示，而不是让请求慢慢排队、最后超时、再触发重试——把三个默认值串起来放大事故。
想听大家聊聊
- 你负责的产品/SDK 里，哪个默认参数「坑过最多用户」？具体是什么数字、什么场景下出的事？
- C 端和 B 端的默认值哲学是不是该彻底分开？（C 端保守到「功能不可用」的边界在哪？）
- 「场景 profile」这套玩法你们落地过吗？维护成本大概多少（按几个配置面 × 几个场景算）？
- 争议最大的一个问题：「默认重试」到底该不该存在——幂等接口重试收益明显，但「判断幂等」这件事用户做不到，SDK 也做不到，那默认值该听谁的？
欢迎直接贴你的事故数字来对线，空谈「看情况」的我会追问情况的。
0赞
0收藏
0楼层