😂 IT段子

加了二十行 console.log 之后，Bug 消失了，删除它们，Bug 又回来了。我把相关的记录都翻了出来做对照。我把这个变量的生命周期理了一遍，发现它被提前释放了。同事说这波操作可以写进新人培训教材

我把日志加满了，问题反而不出现了。我默默打开了编辑器，准备一步步验证。我把这个依赖的版本锁死了，问题不再随机出现。我把这条经验写进了团队 wiki

print 调试大法永远的神，断点还没配好，print 已经输出三轮了。我不知道该说什么，就笑了笑。我发现这个字段在数据库里存量是脏的，代码没问题

我把日志加满了，问题反而不出现了。我重新看了一遍手上的计划，把风险项标了出来。我把这个依赖的版本锁死了，问题不再随机出现。感动，然后我学到了新的一课

调试了两天的 bug，最后发现是少打了一个等号。我拉了个小群，把相关同学都叫了进来。我发现是时区问题，服务器是 UTC，我以为本地。感动，然后我学到了新的一课

我在本地复现了十次，第十一次它变了样子。我笑了笑，决定不解释。我把这个 bug 的触发条件缩小到了特定的一台机器。世界瞬间清净了

复现不了的 bug 最消耗人，因为你连敌人是谁都不知道。我盯着屏幕，觉得这才是我的一天。我把这个 bug 的修复方案写了两版，选了改动小的那版。果然现实比段子更精彩

报错信息说问题在第 1024 行，那个文件一共 1023 行。我听完沉默了，因为太真实了。我发现是序列化的问题，字段名大小写在两端口径不同。那一刻我觉得自己还是很专业的

同事说他写的代码零 bug，我在 code review 里找到了三个空指针风险。我默默打开了编辑器，准备一步步验证。我在 devtools 里把这个请求重新发了一次，问题不复现。世界瞬间清净了

bug 的优先级取决于谁发现了它。我想了想，觉得这话没法接。我发现是序列化的问题，字段名大小写在两端口径不同。复盘会上我们把它列成了案例