6.4 调试技术

调试不是“凭感觉改一行试试”。专业调试是一种调查：复现症状，缩小范围，提出假设，收集证据，验证修复，并留下防回归机制。

越复杂的问题，越需要把猜测变成可观察证据。

先复现，再解释

如果缺陷无法稳定复现，团队很容易把时间花在互相猜测上。复现并不一定要求 100% 出现，但至少要知道触发条件、输入、环境、时间窗口和观察方式。

一个好的复现记录包含：

• 最小步骤。
• 输入数据。
• 环境和版本。
• 期望结果与实际结果。
• 日志、截图、请求 ID 或 trace ID。
• 仍然无法控制的变量。

复现越小，搜索空间越小。

假设要能被证伪

“可能是缓存问题”不是完整假设。更好的表达是：“如果是 CDN 缓存导致，绕过 CDN 的请求应该看到最新头像；如果仍然旧，就排除这个方向。”

好假设应该配套一个低成本实验：

• 需要观察什么？
• 结果 A 说明什么？
• 结果 B 排除什么？
• 下一步会缩小哪个范围？

二分、日志和最小化

当搜索空间有顺序时，可以二分：提交历史、配置范围、输入大小、依赖版本，都可能被切成“好的一边”和“坏的一边”。二分调试的力量来自每次实验都把范围砍掉一大块。

日志和可观测性则帮助你看到系统内部发生了什么。好的日志不是到处打印，而是记录关键边界：请求进入、状态改变、外部调用、重试、异常和用户可见结果。

修复后不要只说“好了”。你还需要：

• 写回归测试或监控。
• 说明根因和触发条件。
• 删除临时调试代码。
• 记录哪些假设被排除。

调试的目标不是赢得争论，而是让事实把系统带回可理解状态。