写/改错误处理路径时：用「三段式显式失败契约」杜绝静默吞错

任何语言、任何仓库中，凡是接触 catch 块、fallback、默认值、重试或降级模式时，按此契约保证每条失败路径都是响亮的。

适用场景

解决思路

1. 确立核心契约：每条 catch 与失败路径必须且只能做以下三件事之一，且三者都要「响亮」。
2. 选项 1：以 WARN 或 ERROR 级别记录日志，然后重新抛出（rethrow）。
3. 选项 2：记录日志并返回类型化的失败，让调用方必须处理（result type、sealed error，或编译器/契约强制下游代码确认的 status）。
4. 选项 3：记录日志并进入显式文档化的降级模式——在代码及其文档中具名，并有可观测信号表明系统正处于降级。
5. 禁止裸 catch-and-continue（捕获后继续执行），无任何例外。
6. 禁止 catch 后返回默认值来掩盖失败：空列表、null、0、缓存副本都不行。
7. 禁止使用 `?? fallback` 及其同类写法掩盖主路径已失败；仅当「缺失」这一事实同时在别处被响亮暴露时，fallback 才可接受。
8. 必需条目缺失要 fail loud：注册表、配置或目录中缺少的条目应导致构建失败或启动失败，绝不允许静默取默认值。
9. 错误状态必须可见：工作流不得在失败时看起来健康，要把错误状态暴露在 UI、指标或运维人员真正会看的日志里。
10. 面向运维的修复提示要具体：写「connection failed, check REDIS_URL and whether redis responds to PING」，而不是「an error occurred」。
11. 重试必须有上界且可观测。
12. 有副作用操作的重放必须幂等。
13. 降级模式必须有边界：skip-and-continue 需要显式阈值来界定何时降级变为中止，该阈值应是一个具名、运维可调的常量；guard 必须存在，其具体取值与 owner 一起判断。无上界的降级模式就是慢动作的吞错。
14. 在失败路径上，可观测性是交付底线而非镀金：日志行、计数器、告警必须与修复一起发布；没有这些的失败路径就是「意图更好的静默吞错」。
15. 编辑到已存在吞错的代码时：作为本次工作的一部分修掉它，或明确标记为待偿并写清它掩盖了什么；默不作声地留着等于为它背书。
16. 代码评审中：新引入的静默吞错是自动 BLOCKER；既有吞错被你碰到却未标记，是对本次变更的 WARNING。
17. 不要用「这永远不会发生」作为吞错的理由——这些路径恰恰是最需要在真的发生时大声告警的。
18. 不要用 DEBUG 级别记一条日志就当作已处理：生产环境没人看得到，那就是多了几步的吞错。
19. 不要用宽泛捕获（`Exception`、`catch {}`）来处理狭窄场景：意外失败会和预期失败一起静默死掉。
20. 不要留下没人文档化的降级模式：只有作者知道的降级，是运维无法诊断的故障。
21. 不要靠给失败兜默认值让测试变绿：测试过了，缺陷却毕业进了生产。

适用边界 · 注意事项

• 唯一例外：只有当「缺失/失败」这一事实已在别处被响亮暴露（UI、指标或有人看的日志）时，才允许使用 fallback 或默认值；无此暴露则本契约不提供任何豁免。
• 本技能只强制「降级阈值这个 guard 必须存在」，不替你决定阈值的具体数值——那是需要与 owner 一起做的判断。