【调试实战】二分定位法：从上百次提交里揪出引入故障的版本

完整课程入口：996 全套课程体系 ｜ Lua 学习路径 ｜ 幂尔框架 mirs.cn

实战应用：用在哪里

"昨天还好好的，今天上线就坏了"——脚本仓库一天几十次提交，逐个回测不现实。二分定位（对齐 git bisect 思路）把 N 次提交的排查压缩到 log2(N) 轮：100 次提交只需 7 轮就能锁定引入故障的那一次。适用于热更脚本仓库、配置表仓库，以及任何"历史版本可以快速验证"的场景。

手工二分的流程

前提条件一个：存在一个"确定好坏"的提交对（昨天的正常版本 + 今天的故障版本）。流程四步：

git checkout 中间提交          # 第 1 轮：50 号提交
# 部署到测试环境复现问题
git checkout 75 号提交         # 仍正常 → 故障在 75~100
git checkout 88 号提交         # 复现 → 故障在 75~88
git checkout 81 号提交         # 正常 → 故障在 81~88
# 3~4 轮后锁定 84 号提交

每轮只回答一个问题："这个版本有没有故障？"答案二选一，范围减半。

脚本项目 Special：不用 git bisect 命令也能做

热更脚本往往不在标准 git 工作流里（FTP 直传目录），二分依然可做：把热更目录按日期快照存档（每轮热更前打包 zip 并记录变更文件清单，前篇热更版本管理的产物正好复用），排查时按快照逐个回放到测试环境验证。快照 + 变更清单的组合，等价于手工版 bisect。

三个提速技巧

先测"特征明显的版本"。 故障与某次活动上线时间吻合时，直接从活动相关的提交开始二分，跳过无关区间。每轮记录结论。 用一张表记录"提交号 | 有无故障 | 验证人"，多人协作时避免重复验证同一版本。锁定后先看 diff 再改代码。 定位到提交后，git diff 上一版 该版 的差异往往几行以内——多数故障在这一步直接水落石出。把二分流程写进团队的故障处理手册，配合热更快照制度，任何"昨天好好的"类问题都会在半小时内收敛到具体改动。