😂 IT段子

这个错误在生产环境是必现的，在测试环境是玄学。我想了想，觉得这话没法接。我加了个 try-catch，先把异常吞掉，回头再查根因。这大概就是程序员的人生吧

我把日志加满了，问题反而不出现了。我在心里把涉及的所有环节都过了一遍。我注释掉了一半代码，bug 消失了，然后我又注释掉了另一半。从此我多了一条团队规约

bug 往往出现在你没改的那部分代码里。我想了想，觉得这话没法接。我盯着那段代码看了二十分钟，最后发现是我自己三天前改的。我把这条经验写进了团队 wiki

我盯了半天，最后发现是拼写和大小写。这套流程走下来，我从头到尾又确认了一遍。我在关键路径上打了十几个日志，一行一行对时间戳。那一刻我觉得自己还是很专业的

调试的本质是不断缩小「问题不在这里」的范围。我停了一下，然后继续手上的活。我在心里给这个 bug 取了个名字，叫「薛定谔的报错」。我沉默了，但心里是服的

调试了两天的 bug，最后发现是少打了一个等号。我拉了个小群，把相关同学都叫了进来。我发现是并发导致的，单线程下它一直是好的。我把这条经验写进了团队 wiki

bug 往往出现在你没改的那部分代码里。我忽然觉得，这可能就是这一行的常态。我加了个 try-catch，先把异常吞掉，回头再查根因。好在最后有惊无险

我把日志加满了，问题反而不出现了。我把整条链路在心里复盘了一遍。我把这个死循环的跳出条件补上了，进程终于不卡了。那一刻我觉得自己还是很专业的

妈妈觉得我在互联网大厂很风光，只有我知道我大厂里的 title 是高级修 bug 工程师。我笑了笑，决定不解释。我把这两次运行的日志逐行 diff 了一遍，找到唯一的差异。复盘会上我们把它列成了案例

调试最花时间的不是修，是确认自己修的是对的地方。我把它记在心里，没跟任何人说。我在心里把这个问题的排查过程复盘了一遍，能省半天。好在最后有惊无险