Bug 总改出新 Bug，怎么调试、怎么写测试才稳？

改 Bug 改出新 Bug，几乎是每个工程师都经历过的循环：修好了 A，却在看不见的地方弄坏了 B。问题往往不在技术能力，而在流程——没复现就动手，没测试就上线。想打破这个循环，可以按下面几步来做。

先复现，再动手

拿到 Bug 的第一反应不该是打开编辑器改代码，而是想办法稳定复现它。能稳定复现的 Bug 才算真正被“抓住”：你知道触发条件、输入数据和预期输出的差距。复现时顺手记录完整的环境信息——版本号、配置、输入数据、相关日志。如果暂时复现不了，先补日志、加埋点，把线索攒够再说。跳过这一步直接改，很容易只治了表象，真正的病灶还埋在里面，过几天换个姿势再爆一次。

二分定位，再给关键逻辑补单测

定位难缠的 Bug，二分是最朴素的武器：先判断问题在这半边还是那半边。注释掉一半逻辑，看结果是否变化；或者在提交历史里用 git bisect 逐次对半排查，几十次提交的历史，几轮就能锁定引入问题的那次改动。定位到具体代码后，修复之前先写一个会失败的测试（红灯），修完让它变绿。这个测试从此就是资产：将来谁改坏了这块逻辑，测试会立刻报警。单测不必追求覆盖率数字，优先覆盖三类地方：分支最多的核心函数、边界条件（空值、极值、并发场景）、历史上出过 Bug 的位置——出过一次的地方，很容易再出第二次。

维护一份回归清单

项目里修过的 Bug，值得记成一份简单的回归清单：现象、根因、修复方式、影响的模块。每次发版前，把清单上的关键场景手动或自动过一遍。这份清单起初看着麻烦，但它会在某个时刻救你一命——尤其是人员流动之后，新同事能靠它快速了解系统的“雷区”分布，老问题也不容易换一层皮重新出现。

说到底，“改出新 Bug”的本质，是改动的影响面超出了你的认知面。复现划定边界，二分加速定位，测试固化认知，回归清单守住防线。这四件事没有一件很难，难的是每次都肯做。