遇到 Bug 不要慌：一套通用排查思路

程序员的工作日常中，写代码可能只占 30%，剩下的 70% 往往是在阅读代码、理解代码和修复 Bug。

面对一个突如其来的 Bug，尤其是生产环境下的报错，人类的本能反应是"恐慌"和"猜测"：

"是不是数据库挂了？" "是不是昨天那个同事改了我的代码？" "是不是服务器内存溢出了？"

这种"乱枪打鸟"式的排查，不仅效率低下，还往往会引入新的 Bug。Debug 不是玄学，而是一门严谨的科学实验。

要成为一名高效的解决问题者，你需要克制住动手改代码的冲动，严格遵守一套通用流程：复现 → 定位 → 最小化 → 验证。

"无法复现的 Bug，就等于不存在。"

在动手查代码之前，你必须先让 Bug 在你的控制下再次发生。这不仅是为了确认问题不是幻觉，更是为了建立后续排查的"观测基准"。

记录操作路径：详细记录你是通过什么点击顺序、输入什么数据、在什么环境下触发 Bug 的。
控制变量 ：
- 是所有用户都有这个问题，还是仅限特定账号？
- 是在 Chrome 浏览器发生，还是 Safari 也有？
- 是必现，还是偶发（10次里出现1次）？
检查环境：确保本地环境配置、数据版本与出问题的环境一致。

心态转变： 如果你是第一次遇到 Bug，千万不要去修。先写一个测试脚本或操作手册，确保任何人运行这个脚本都能让 Bug 显灵。能复现，你就赢了一半。

确认问题存在后，接下来就是寻找"病灶"。很多初级程序员喜欢从头读到尾，这是低效的。你需要使用"二分法"和"排除法"。

日志与断点（Log & Breakpoint） ：
- 在代码逻辑的上游和下游分别打日志或下断点。
- 二分排查：如果代码有 100 行，先在第 50 行看数据是否正常。如果正常，问题在 50-100 行；如果异常，问题在 1-50 行。
排除法 ：
- 是前端问题还是后端问题？（看 Network 请求，状态码是 200 还是 500？返回数据对不对？）
- 是数据问题还是逻辑问题？（直接查数据库，看存进去的数据是否脏了？）
版本回溯 ：
- 如果是新出现的 Bug，使用 git bisect 命令或回滚最近的提交，快速定位是哪一次 Commit 引入的问题。

核心目标： 将排查范围从"整个系统"缩小到"某个函数"甚至"某一行代码"。

这是区分普通程序员和高手的关键一步。当你定位到大概的代码区域后，周围的逻辑可能非常复杂（牵扯到权限、缓存、异步回调等）。

不要在这个复杂的迷宫里修修补补，请把问题"提取"出来。

剥离业务逻辑：将出错的代码片段复制出来，去掉业务无关的装饰、UI 组件、复杂的权限判断。
构造最小复现用例 ：
- 比如一个排序算法错了，不要在整个电商系统里测。新建一个文件，只写那个排序函数，输入你刚才复现 Bug 时用的那几条数据。
- 如果问题依然存在，恭喜你，你得到了一个纯净的 Bug 标本。
为什么这一步最重要？
- ** clarity（清晰度）**：在复杂的上下文中，你的大脑会被干扰。在最小化代码中，Bug 的原因会显而易见（例如：原来是变量名拼错了，或者是边界条件没考虑）。
- 可求助性：当你需要求助同事或 AI 时，甩给他们一个 10 行的最小化代码片段，他们能秒回；甩给他们 1000 行业务代码，没人会看。

找到原因并修改代码后，很多程序员就迫不及待地点击发布按钮了。慢着，你的修复可能只是掩盖了症状，而非根治了病根。

回归第一步的复现步骤 ：
- 运行你在第一步记录的操作路径。确认 Bug 真的消失了，而不是"好像不报错了"。
思考副作用 ：
- 你的修改会不会影响其他正常的流程？这往往是"修复一个 Bug，产生两个新 Bug"的根源。
添加防护网（自动化测试） ：
- 将你第三步构造的"最小化复现用例"转化为单元测试或集成测试代码。
- 永远不要让同一个 Bug 咬你两次。 把这个测试加入 CI/CD 流程，确保未来没人能通过改代码把这个问题再次引进来。

Debug 的本质，是在混乱的信息中建立秩序。

下次再看到红色的报错信息，深吸一口气，打开记事本，写下："复现步骤..."。当你开始执行这套流程时，你就已经不再是被 Bug 吓坏的新手，而是掌控局面的猎人。