展开知识库目录
偶发 Bug 怎样用日志、时间线和最小复现缩小范围
先把每次出现时的输入、环境、请求、资源和日志关联起来，寻找共同条件。
偶发 Bug 需要时间线，不需要更多猜测
先把每次出现时的输入、环境、请求、资源和日志关联起来，寻找共同条件。没有时间戳和请求 ID 的日志很难证明因果。
定义可观察症状
写用户看到什么、频率、首次时间、影响对象和成功对照，不用“偶尔坏了”。
把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。
建立端到端关联
为一次操作关联前端事件、请求 ID、应用日志、数据库和外部依赖时间，统一时区。
确认“建立端到端关联”已经有可回查结果，再进入“收集成功与失败样本”；依据仍然来自猜测时，把缺口单列并停在当前步骤。
收集成功与失败样本
比较输入、版本、节点、负载、缓存和延迟，找只在失败组出现的条件。
确认“收集成功与失败样本”已经有可回查结果，再进入“缩成最小复现”；依据仍然来自猜测时，把缺口单列并停在当前步骤。
缩成最小复现
控制一个变量逐步提高复现概率，使用可逆测试环境和模拟故障，避免在生产随机尝试。
确认“缩成最小复现”已经有可回查结果，再进入“验证假设与修复”；依据仍然来自猜测时，把缺口单列并停在当前步骤。
验证假设与修复
先用实验让症状出现或消失，再改代码；上线后设观察窗口和同一指标。
需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“最小复现与证据时间线”。
完成后应能在“最小复现与证据时间线”中找到与这一步对应的记录；仍需靠猜测补全，就停在这里。
时间线应区分事实、推断和未知
根因只在实验或日志闭环后确认。无法稳定复现时交付已知触发条件、观测改进和下一次捕获方案，不制造确定答案。