😂 IT段子

bug 的优先级取决于谁发现了它。我发现自己居然没法反驳。我在 devtools 里把这个请求重新发了一次，问题不复现。那一刻我觉得自己还是很专业的

复现不了的 bug 最消耗人，因为你连敌人是谁都不知道。我盯着屏幕，觉得这才是我的一天。我把这个变量的生命周期理了一遍，发现它被提前释放了。真香定律准时生效

这个空指针在上线前一切正常，因为那时没有空数据。我笑了笑，决定不解释。我在关键路径上打了十几个日志，一行一行对时间戳。我沉默了，但心里是服的

我把日志加满了，问题反而不出现了。我把手上的资料翻出来又读了两遍。我把这两次运行的日志逐行 diff 了一遍，找到唯一的差异。我把这条经验写进了团队 wiki

报错信息说问题在第 1024 行，那个文件一共 1023 行。我笑了笑，决定不解释。我把这个 bug 的优先级降了一级，因为它只在测试环境出现。真香定律准时生效

我把这个堆栈从头读到尾，关键信息在最后一行。我打开记录从头到尾扫了一遍。我把这个 bug 的优先级降了一级，因为它只在测试环境出现。好在最后有惊无险

同事说他写的代码零 bug，我在 code review 里找到了三个空指针风险。我重新看了一遍手上的计划，把风险项标了出来。我发现是时区问题，服务器是 UTC，我以为本地。同事说这波操作可以写进新人培训教材

调试是有惯性的，停下来反而更容易想通。我盯着屏幕，觉得这才是我的一天。我在本地把这段代码跑了一千遍，一次都没复现。果然现实比段子更精彩

调试最花时间的不是修，是确认自己修的是对的地方。我发现自己居然没法反驳。我把这个报错的堆栈从头读到尾，发现在最后一行有个提示

这个报错信息指向的位置和真正的错误隔了三层。我默默记下了这句话。我在生产环境复现了一次，代价是一个小时的下线。我把它写进了组内的避坑文档第一章