调试不是追着报错跑：用最小程序验证一个假设

面对异常输出时，最容易发生的事情是连续修改很多地方，直到问题暂时消失。这样做可能让程序恢复运行，却没有解释真正原因。调试更适合被理解为一连串有记录的假设检验。

本文以自己的本地小程序为范围，讨论观察方法，不涉及对外部服务的测试。目标是把“好像哪里不对”转化为能够重复验证的问题。

先描述预期与实际的差别

记录输入条件、预期结果、实际结果和运行环境。描述应尽量具体，例如某个变量在一次循环之后与预期不同，而不只是写“程序崩了”。如果有报错信息，保留必要上下文，但不要把敏感数据放进公开笔记。

重复运行同一输入，确认现象是否稳定。如果结果并不稳定，也应把这种不稳定当成观察结果记录，而不是选择一次最符合自己猜测的输出来解释整个问题。

缩小示例，但保留触发条件

逐步移除与现象无关的代码，每次移除后重新验证。最小示例的价值在于减少解释的可能性，而不是追求最少字符。如果删掉某部分后问题消失，说明它可能与触发条件有关，需要恢复并继续分析。

在笔记中保留原始版本和简化版本的对应关系。否则，当你从一个复杂项目提取出小例子后，可能已经无意改变了数据生命周期、编译条件或调用顺序。

用观察点检验明确预测

先写出假设，例如“进入这一分支前，计数值已经被改变”。再选择合适的观察点，检查相关状态。调试器、日志或断言各有用途，具体工具操作应以当前版本文档为准。

一次只验证一个主要判断。若观察结果不支持假设，就记录并更换解释，而不是不断移动目标。能够排除一种原因，也是一项有效成果。

修复之后保留一个回归检查

解释导致现象的条件，再设计覆盖该条件的检查。如果只验证一个理想输入，可能遗漏相邻的边界情况。适当增加空输入、最小值或长度边界等项目，但应根据程序功能选择，而不是机械地套用清单。

最终记录应该让另一位学习者能够读懂问题、复现现象并理解修复理由。清楚的因果说明，比一张看起来复杂的调试界面截图更能体现理解程度。