本页目录
改了两处代码，bug 消失了——但你不知道哪处改对了
最高频的调试事故。线上出了问题，你看到两处可疑代码，顺手一起改了。部署，问题没了。
一周后同一个 bug 又出现。因为两处修改里只有一处是有效的，另一处恰好掩盖了某个中间状态。你退回去排查，发现已经没办法隔离变量了——当时的环境、状态和复现条件都没记录。
Agans 的规则很简单：一次只改一个变量。改之前记下当前状态，改之后确认结果。如果问题没变化，退回来，换下一个变量。
这条规则的敌人是你的手速和焦虑。越着急越想一口气全改掉，但每多改一个变量，调试的复杂度就翻一倍。
"应该不是这里的问题"——然后它偏偏就是
接手一个生产故障。第一反应："数据库不可能有问题，上周刚做过维护。"于是跳过数据库，从应用层查起。查了三小时，最后发现是数据库连接池配置变了。
"应该不是"是猜测，不是观察。Agans 的"别猜了，去看"就堵这个口：你凭什么排除它？看过日志吗？跑过测试吗？如果答案是"凭经验"——经验在这个场景下可能正好错了。
排除一个可能性需要证据，不需要直觉。
bug 时灵时现，你决定等它"自己复现"
一个报错，测试环境跑三次只出现一次。"先做别的，等下次出现再看。"——三天后再也没出现过。直到上线那天，它在生产环境稳定复现了。
Agans 把"让它出错"列为核心规则。偶发 bug 不是不能复现，是你还没找到触发条件。缩小变量范围：换网络环境试、换数据量级试、换并发数试。能稳定复现的那一刻，你就赢了一半。
找不到触发条件本身也是信息——说明你对系统的某个环节理解不够。
新人调不出来，高手五分钟搞定——因为高手先看了文档
一个嵌入式设备的通信故障。新工程师折腾了两天，换线、换芯片、重刷固件。高手来了，先翻了硬件手册，发现这款芯片的 SPI 时钟极性有个非默认配置。改一个寄存器，通了。
差距不在调试技巧，在"理解系统"这条规则。新人跳过了读手册这一步，直接进入试错循环。高手的"快"不是反应快——是知道该去哪找答案。
插头没插，你检查了整条链路
经典案例。一台打印机不工作。检查驱动、检查端口、检查网络、检查队列。折腾了一上午，最后发现电源线松了。
Agans 把"检查插头"单独列成一条规则，因为人的直觉总是先排查复杂原因。简单原因不体面，不像"正经的调试"。但最蠢的原因往往最致命——因为它被检查得最晚。
实际场景不一定是物理插头。可以是环境变量没设、DNS 指向错了、配置文件用的是上个环境的。先花一分钟排除最简单的可能，再进入复杂分析。