日志与调试
复习
- 契约、错误与异常：错误应明确暴露
- 网络故障诊断：分层排查问题
- 从算法到软件：软件要正确，也要能被验证
TL;DR
- 调试是从现象出发，逐步缩小错误范围
- 日志是程序留下的“现场记录”
- 先提出假设，再用证据验证
- 好的日志让问题可被重现和定位
正文
无论写得多小心，程序总会有 bug。调试（debugging）就是找出并修掉它们的过程。而日志（logging），是让这件事变得容易的关键工具。
调试的思路
调试最忌讳的，是“凭感觉乱改代码”。更有效的做法是科学一点：
- 观察现象：到底哪里不对、什么时候不对
- 提出假设：猜一个可能的原因
- 设计验证：怎么用最小的实验，证明或推翻这个假设
- 缩小范围：根据结果，把问题可能存在的范围砍掉一半，重复
这和前面网络故障诊断里的“分层排查”是一个思路：每次都把可能性砍掉一大块，而不是四处瞎猜。 范围越小，离真相越近。
让问题可重现
调试里有一句话：能稳定重现的问题，就等于解决了一半。 因为只有能重现，你才能反复试验、验证假设。
如果一个 bug 时有时无，那多半和某些特定条件有关——特定的输入、特定的时序、特定的环境。找到这些条件，让它稳定重现，往往比直接改代码更重要。
日志：程序的现场记录
如果程序已经跑在用户那里、无法直接调试呢？这时日志就派上用场了。
日志是程序运行时留下的“现场记录”：它记下发生了什么、在哪一步、关键数据是什么。有了它，即使问题发生在别人的机器上，你也能“回放”出事发前后的情况。
好的日志有几个要点：
- 有级别：比如“普通信息 / 警告 / 错误”，便于按需查看
- 有上下文：记录足够的信息（时间、位置、关键变量），而不只是“出错了”
- 不泄露敏感信息：密码、密钥之类绝不能写进日志
日志的价值，在于它把“事后无法复现的问题”，变成“有据可查的线索”。 平时可能不起眼，出事时就是救命稻草。
思考题 1
调试时，为什么“先提出假设再验证”比“乱改代码”更有效？
思考题 2
为什么说“好的日志”能大幅缩短排查时间？
小结
知识点
- 调试是观察、假设、验证、缩小范围的过程
- 让问题稳定重现往往事半功倍
- 日志记录程序运行时的关键信息
- 日志应有级别、有上下文且不泄露敏感信息
参考资料
- Wikipedia(zh)：调试：定位并修复程序错误
- Wikipedia(zh)：日志文件：程序运行时记录的信息
思考题答案（仅供参考）
思考题 1
因为“先假设再验证”能让每一步都有依据地缩小问题范围，方向明确、可累积。乱改代码则可能掩盖真因、引入新问题，即便偶然修好也不知道为什么，效率低且不可靠。
思考题 2
因为日志记录了程序运行时的现场信息。当问题难以直接复现（比如发生在用户处）时，日志能帮助还原出事的条件与经过，从而快速定位线索，避免“两眼一抹黑”地猜测。
协议
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
封面图
设计师 | 南国微雪