原始笔记是一段连贯的读书随笔，结构稍乱（小标题列了一遍后又重新展开）。这里删掉重复的目录式列表，按”开篇 / 九条规则 / 总结”组织，原文要点保持不动。
当前保留内容
开篇
最近两周读完了《调试九法》，顺带认真想了一下”调试”究竟是什么——
- 对程序员来讲，调试就是 Debug，消除代码中的 Bug。
- 对硬件工程师来讲，调试就是找出硬件出错的原因。
- 抽象来讲，调试就是找出问题的原因，并研究如何去解决。
《调试九法》通过作者亲历的多种案例，逐一说明如何解决问题；按下面九条规则去做，往往能很快找到方法。
规则一 理解系统
遇到问题时，先判断自己使用工具的方式是不是正确，是否符合预期。
很多简单代码跑出非预期结果，最后发现只是函数调用方式不对，或者参数类型不对——先回去翻一下相关说明文档，往往就能找到答案。
规则二 制造失败
衡量 Bug 的一个指标是复现率：
- 复现率 100% 的 Bug 容易定位、容易观察、容易调试。
- 复现率低或周期性出现的 Bug，要想办法让它更容易复现。
注意：不要”模拟失败”——模拟环境不一定等价于 Bug 现场，要尽量在现场用工具观察。
规则三 不要想，而要看
调试时多观察，少猜测。复现 Bug 后，用 log、GDB 等工具认真去看；单纯靠猜并改代码，往往精疲力尽却毫无头绪。
这一条还提到插装思路：用各种外部组件，在不影响程序内部运行的前提下，观察其内部状态。
规则四 分而治之
类似二分查找：
- 可疑区域很广时，用方法逐步缩小可疑区间。
- Bug 涉及多个分支时，从根节点开始逐一确认，逐步定位到”叶子节点”。
规则五 一次只改一个地方
类似对照实验——对照条件只能有一个，否则无法确定哪个变量带来了变化。
如果怀疑两段代码都有问题，不要同时改，逐一修改、逐一观察对最终结果的影响，每次修改都要与正常结果对比。
规则六 保持审计跟踪
操作复杂时，一定要用某种方式记录修改结果——经历多轮修改后人很容易忘记自己做过什么。代码版本控制工具就是为此而生：新功能上线后若出现问题，可以方便地回滚到上一个版本，并对比新提交。
作者还提到一点：让不熟悉系统的人使用一个工具时，用尽可能详细的语言描述用法；这样作为系统开发者也更容易定位问题。
规则七 检查插头
引入新组件后，在调用代码块里加上异常捕捉逻辑。复杂组件本质上是黑箱，无法研究内部逻辑，最简单的应对就是封装这个组件、考虑所有可能的异常输出并处理。
规则八 获得全新观点
碰到难题时多虚心向他人求助——别人也许已经踩过无数次坑。一个人硬扛，往往浪费精力；站在巨人肩膀上才能看得更高。
求助时要客观陈述事实，不要带入自己的猜测，否则容易把别人带偏。类比看病：要细说症状，不要先下”我可能感冒了”的结论。
规则九 如果你不修复 bug，它将依然存在
这一条是劝我们尽可能真的去解决 Bug。先确认 Bug 是不是真的解决了：
- 添加解决方法 → Bug 消失
- 移除解决方法 → Bug 复现
- 再次添加解决方法 → Bug 消失
很多 Bug 会随时间淡出视野，但作为 Bug 的制造者，错误的思维会留在大脑里，下一次极有可能在另一个系统里复现。重要的是纠正自己错误的想法、找到真正的解决办法。
整体总结
《调试九法》的确是本好书，里面的思维抽象出来可以延伸到任何问题的解决思路。后续要认真领悟，并尝试把这九个原则用到日常的每个问题上。
后续可补的方向
- 每条规则配 1～2 个自己的实战案例（线上事故 / 偶现 Bug 等）
- 在团队内部把九法落到具体流程：oncall checklist、事故复盘模板
- 与 SRE 的”ABC——Always Be Curious”、Google 事故复盘文化做对照
