Bug 复现、定位与修复流程

修 Bug 最忌"看到报错就打补丁"。先稳定复现、定位根因、再做最小修复并回归验证，才能避免同一问题反复出现。本节把缺陷修复拆成可重复执行的流程，配合版本控制与验证习惯，让每次修复都小、准、可回退。

一、缺陷修复六步流程

1. 稳定复现：整理出可重复触发的最小操作步骤，明确预期行为与实际行为的差异。
2. 缩小范围：用最小输入、最小分支定位问题出现的条件，排除无关模块与环境噪声。
3. 定位根因：沿报错信息与调用链找到真正出错的代码位置与触发原因，区分"根因"和"表面症状"。
4. 最小修复：只针对根因改动必要代码，不借修缺陷之名做无关重构或功能增强。
5. 回归验证：先验证原场景已恢复，再跑相关测试与相邻路径，确认没有引入新问题。
6. 防回归：为缺陷场景补一条能复现该问题的检查，把修复结果固化，防止后续改动再次破坏。

二、复现阶段应收集的信息

信息项	为什么需要
触发步骤与输入数据	让代理能够在受控条件下重复同一现象，而不是凭描述推测
预期结果与实际结果	明确判断标准，避免把"设计如此"误判为缺陷，也避免修复后仍不满足预期
完整报错信息与栈位置	指向首个失败点；只截取最后一行容易误判责任模块
环境与版本前提	运行环境、依赖版本、配置差异可能直接决定是否触发，需一并交代
出现范围	是必现、偶现、特定数据下出现还是特定操作顺序触发，决定排查方向
相关近期改动	用版本历史对照最近变更，可快速锁定引入缺陷的改动面

三、定位根因的常用方法

• 从首个报错点向下追：先定位抛出错误的位置，再沿调用方向确认输入为何异常，而不是停在最外层提示。
• 改动对比缩小嫌疑：结合 git diff 与历史提交判断问题是否由近期改动引入，先排除已知变更再查固有逻辑。
• 先提出假设再验证：形成"某条件导致某路径取值错误"的明确假设，构造最小用例证实或证伪，避免四处乱改。
• 区分缺陷与设计缺失：行为与规格不符是 Bug；规格未覆盖属于需求缺失，应另行补充而非在修复中夹带。
• 警惕连锁反应：一处异常可能由上游数据问题引起，修复点应落在错误真正产生的位置。

四、最小修复与安全回退

原则	具体做法
改动克制	只修改导致根因的最小片段，保持其余逻辑与命名不变
验证先行	修复后先跑相关测试/构建；失败的中间尝试不叠加后续修改
可回退	实验性修改未确认前不提交；需要放弃时用 git restore 回到干净基线
提交清晰	确认有效后由人工 git add、git commit，提交信息说明缺陷、根因与修复要点
不过度防御	必要的健壮性保护可以加，但与根因无关的宽泛兜底会掩盖真实问题，应分开评估

五、FAQ

问题	处理建议
无法稳定复现怎么办	先收集触发规律与日志线索，缩小数据/环境条件，优先补充观测与检查，不急于改代码。
代理一次修了好几处问题	用 git diff 拆分审阅；多个独立缺陷分别处理、分别验证，避免一个提交混入多处改动。
修复后测试仍报错	先判断是修复引入还是既有失败；定位首个失败点，不通过删除或跳过测试来"变绿"。
根因涉及公共模块	先评估影响面与兼容性，必要时采用向后兼容修复并补充回归覆盖，再统一调整调用方。

六、动手练习

• 练习：挑一个历史缺陷，按六步流程整理"复现步骤—根因假设—最小修复点—回归验证—防回归检查"，对照真实提交看修复是否克制、是否可回退。