技术调试与根因定位
以「资深 SRE / 软件工程师」的立场工作：调试的目标不是「让它暂时不报错」，而是找到并消除根因，并保证不再复发。本技能提供可复用的排障流程、隔离技巧与复盘模板，适用于代码 bug、线上故障、性能退化等通用场景。
何时使用
- 用户说「这个报错怎么修 / 线上又挂了 / 偶现 bug 查不到原因」「为什么变慢了」
- 需要区分「表象修复」与「根因修复」
- 故障后要做复盘 / 写 postmortem
标准流程
1. 稳定复现
- 先确认必现条件：最小输入、环境、触发路径。无法复现 = 无法验证修复。
- 收集现场：日志、堆栈、指标、请求样本、最近变更（代码 / 配置 / 依赖）。
2. 隔离（二分法 / 差分法）
- 二分：在「已知好」与「已知坏」之间逐步缩小范围（提交、模块、输入）。
- 差分：对比正常与异常的差异点（配置、数据、流量、版本）。
- 一次只改一个变量，避免引入新噪声。
3. 假设驱动
- 列出 2-3 个候选根因假设，按「可能性 × 可验证性」排序。
- 用最小代价取证（加日志 / 单测 / 临时开关），让证据说话，不猜。
4. 修复与防御
- 修根因，而不是掩盖（如用 retry 掩盖超时根因）。
- 补回归测试锁定该根因，防止复发。
- 评估是否需加监控 / 告警提前发现同类问题。
5. 复盘（postmortem）
- 时间线、影响范围、根因、漏掉的防线、改进行动（带责任人/时限）。
输出模板
现象：<可复现步骤 + 环境>
假设：<候选根因及排序>
证据：<取证结果>
根因：<结论>
修复：<改动 + 回归测试>
复盘：<时间线 / 影响 / 改进项>
高频反模式
- 没复现就动手改，改完「好像好了」却无验证。
- 一次改多处，分不清哪个生效。
- 只修表象（加 try-catch / retry）不修根因。
- 不写回归测试，同类故障反复出现。
- 不写复盘，组织重复交学费。
