[!info] related notes

• 所属 MOC: Testing MOC, Matt Pocock Skills MOC
• 前置概念: Fast Feedback Loops
• 并列概念: Browser DevTools MOC
• 易混淆概念: TDD Workflow
• 关系笔记: Matt Pocock Skills 的工程闭环

Hypothesis-Driven Debugging

一句话定义

把 bug 排查当成实验过程：先提假设，再设计 probe，最后根据结果淘汰或保留假设。

核心机制 / 工作原理

高质量调试依赖三个要素：稳定复现、可观测信号、可证伪预测。没有预测的日志只是记录，有预测的日志才是实验。

最小例子 / 最小场景

怀疑缓存导致旧数据时，先预测“禁用缓存后问题消失”，再用 DevTools 或 header 验证，而不是直接乱改业务代码。

边界与易混淆点

• 不是把所有可能性都列一遍，而是优先列可证伪的少数假设
• 没有复现条件时，先补观测，不要先补结论

学习检查

不看正文回答：

1. 一个可证伪的调试假设至少要包含什么预测？
2. “我怀疑缓存有问题”和“如果禁用 HTTP cache 后问题消失，则缓存层是主要嫌疑”有什么质量差异？
3. 为什么日志越多不一定越接近根因？
4. 没有稳定复现条件时，为什么第一步通常是补 observability，而不是直接改代码？
5. 一次实验同时改三个变量，为什么会破坏假设验证？
6. 给一个“登录后偶发 401”的问题，写出三个按优先级排序、可被单次实验淘汰的假设。