😂 IT段子

bug 的优先级取决于谁发现了它。我想了想自己这些年，好像确实如此。我把这个异常上报到了监控平台，至少下次能早点知道。感动，然后我学到了新的一课

加了二十行 console.log 之后，Bug 消失了，删除它们，Bug 又回来了。我打开记录从头到尾扫了一遍。我加了个 try-catch，先把异常吞掉，回头再查根因。那一刻我觉得自己还是很专业的

bug 往往出现在你没改的那部分代码里。我发现自己居然没法反驳。我在关键路径上打了十几个日志，一行一行对时间戳。从此我多了一条团队规约

print 调试大法永远的神，断点还没配好，print 已经输出三轮了。我发现自己居然没法反驳。我发现是序列化的问题，字段名大小写在两端口径不同。同事说这波操作可以写进新人培训教材

我在本地复现了十次，第十一次它变了样子。我忽然觉得，这可能就是这一行的常态。我把这个内存泄漏的对象引用链打了出来，找到根了。第二天这个方案就变成了团队标准做法

报错信息说问题在第 1024 行，那个文件一共 1023 行。我听完沉默了，因为太真实了。我在心里给这个 bug 取了个名字，叫「薛定谔的报错」。世界瞬间清净了

调试最花时间的不是修，是确认自己修的是对的地方。我听完沉默了，因为太真实了。我发现这个问题只在周一早上出现，后来知道是定时任务。从此我多了一条团队规约

我把日志加满了，问题反而不出现了。我盯着那段代码看了二十分钟，最后发现是我自己三天前改的。感动，然后我学到了新的一课

调试最花时间的不是修，是确认自己修的是对的地方。我想了想自己这些年，好像确实如此。我发现这个接口在特定参数组合下返回了空对象。幸好之前留了备份

这个 bug 的修复方案有两版，简单的那版风险更大。我在心里点了点头。我在心里把这个 bug 的可能性列了五条，第一条就对了。好在最后有惊无险