在很多系统里，“兜底”被视为一种美德：
- 接口失败了，兜底
- 下游超时了，兜底
- 数据不一致了，兜底
- 状态异常了，兜底
看起来系统非常“健壮”。
但现实却一次次证明：
兜底写得越多，
系统往往死得越惨。
一、兜底的初衷，和它的真实效果
兜底的本意是：
“不要因为一个点失败，拖垮整个系统。”
这在局部是正确的。
但当兜底开始无处不在时，
系统会悄悄发生一个转变：
从“失败即异常”，
变成“失败是正常状态”。
二、兜底是如何一步步削弱系统的？
1️⃣ 失败被掩盖
兜底逻辑最擅长做的事情是：
- 把错误变成“看起来还能用”
- 把异常变成“暂时成功”
结果是：
- 监控失真
- 报警延迟
- 问题积累
系统在“带病运行”。
2️⃣ 错误路径被频繁走通
一旦兜底成为常态：
- 正确路径和错误路径的界限开始模糊
- 系统开始“依赖兜底才能成功”
这是一种极其危险的状态：
兜底从保护措施，
变成了系统正常运行的一部分。
3️⃣ 行为语义被破坏
例如：
- 下单失败但返回成功
- 状态未更新但流程继续
- 数据不完整但触发后续逻辑
短期看似平稳，
长期却让系统行为不可解释。
三、为什么兜底越多，系统越难维护？
因为兜底会制造：
- 隐式分支
- 非显式状态
- 隐藏副作用
- 非对称行为
你再也无法回答一个简单问题：
“这个操作成功，到底意味着什么？”
四、顶级系统反而“兜底很少”
你会发现：
- 真正稳定的系统
- 核心链路兜底极少
- 非法状态直接失败
- 异常明确暴露
它们并不是不怕失败，
而是明白一个事实：
明确的失败，
比模糊的成功要安全得多。
五、什么时候才应该兜底？
一个非常清晰的原则是：
只有在“业务语义仍然成立”的情况下，
才允许兜底。
例如：
- 推荐失败 → 返回空列表（语义仍成立）
- 日志失败 → 不影响主流程
但像下面这些兜底，往往是灾难源头：
- 交易失败但返回成功
- 状态更新失败但继续流程
- 校验失败但默认通过
六、一个反直觉但极其重要的结论
系统的稳定性，
不是靠“尽量不失败”，
而是靠
“失败时行为仍然清晰”。
