第13章 Bug修复与调试
第12章讨论的是如何根据既定规范生成新的实现，本章则转向另一类性质不同的编码活动：在代码已经存在但出现异常行为时，如何定位原因并完成修复。Bug修复并不是根据故障现象直接修改代码。用户看到的通常只是最终症状，真正原因可能位于输入数据、状态转换、并发时序、配置环境、外部依赖或多个模块的交互之中。调试的任务，是通过可复现的证据和逐步收窄的搜索过程建立故障症状与代码原因之间的联系；修复的任务，则是在确认原因后实施范围受控的修改，并证明原有问题得到解决且没有引入新的回归。
第11章把Bug修复列为五类核心工作流之一，并指出任务描述的质量会直接影响委托效果。本章将进一步讨论这一工作流：当失败行为能够稳定复现时，如何把准确表达预期结果的失败测试转化为可执行的问题规范；当问题暂时无法复现时，如何利用日志、调用轨迹、状态快照和环境信息建立替代证据；如何通过补充诊断信息逐步缩小搜索空间；以及如何把“提出假设—实施修改—运行验证”的调试过程组织为有界的自动化循环，并在连续失败、证据不足或涉及重要决策时及时升级给人处理。
本章还将接续第9章留下的IoTFlow案例。网络抖动会使网关把同一次设备离线过程上报为多个事件，进而触发重复告警。第9章通过混沌工程暴露了这一问题，并把观察到的失败行为固化为回归测试，但没有继续决定应当在网关层去重，还是把事件交给告警引擎结合更多上下文判断。本章将从这条失败测试出发，演示初步修复、发现新回归、补充诊断证据、调整实现和验证架构决策的完整过程。
读完本章，读者应能为Bug修复构造可执行的问题规范，根据问题的可复现程度选择相应的证据收集方法，利用诊断信息缩小原因搜索范围，组织具有重试上限和升级条件的自动化调试循环，并通过回归测试和更大范围的验证判断修复是否真正成立。贯穿这些方法的基本原则是：Bug修复不能以“代码已经改动”作为完成标志，而应以故障原因得到证据支持、失败行为不再出现且相关既有行为保持不变作为验收依据。