调试方法论

问题：直觉调试的代价

遇到间歇性 502 错误时，常见做法是反复重启服务或调整超时配置。这类操作看似解决了问题，实则可能掩盖真实根因，甚至引入新的风险。当 bug 与环境相关、偶现或涉及性能瓶颈时，直觉驱动的调试方式往往效率低下且不可复现。

核心能力与关键步骤

调试方法论 技能通过结构化工作流，将调试过程从“试错”转为“验证”：

• 稳定复现：强制记录环境、输入、预期与实际输出。无法复现的 bug 优先添加日志而非猜测。
• 二分法定位：通过 代码二分（注释模块）、git bisect（定位引入 commit）或 数据二分（缩小输入集）逐层缩小问题范围。
• 信息收集：整合日志分级（ERROR/WARN/INFO/DEBUG）、断点调试和网络抓包，避免遗漏关键线索。
• 假设-验证循环：每轮仅修改一个变量，设计最小验证实验并记录结果，防止多变量修改导致归因混乱。
• 5 Whys 根因分析：从现象出发连续追问，例如：

- 为什么超时？→ 慢查询
- 为什么慢查询？→ 缺少索引
- 为什么缺少索引？→ 未执行迁移脚本
- 为什么未执行？→ CI 流程未包含该步骤

• 修复与回归：采用最小修改策略，补充测试用例并执行全量回归验证，输出结构化 DebugReport。

适用边界与注意事项

• 不适用场景：拼写错误、语法错误等一眼可定位的问题无需使用此方法论。
• 工具依赖：需配合 git bisect、日志系统和测试框架使用，纯手动调试环境可能限制二分法效率。
• 环境复杂性：涉及多服务交互或分布式系统时，需额外补充链路追踪和日志关联分析。

方法论的价值在于强制建立可验证的调试链条，而非替代实际代码分析。它要求开发者先成为冷静的观察者，再做精准的手术刀。