😂 IT段子

程序员的墨菲定律：演示的时候必出 bug，删掉的那段代码才是有用的。我笑了笑，决定不解释。我在心里把这个 bug 的可能性列了五条，第一条就对了。真香定律准时生效

我用了半天才明白，问题不在这台机器上。这套流程走下来，我从头到尾又确认了一遍。我在 devtools 里把这个请求重新发了一次，问题不复现。那一刻我觉得自己还是很专业的

程序员的墨菲定律：演示的时候必出 bug，删掉的那段代码才是有用的。我听完沉默了，因为太真实了。我发现这个字段在数据库里存量是脏的，代码没问题。果然现实比段子更精彩

报错信息说问题在第 1024 行，那个文件一共 1023 行。我愣了两秒，然后继续敲代码。我在生产环境复现了一次，代价是一个小时的下线。好在最后有惊无险

线上日志里出现了从未见过的堆栈，时间戳还是三个月前的。我盯着屏幕沉默了十分钟。我把这个问题交给了上游，他们说是我们的调用方式不对。从此我多了一条团队规约

我把这段代码注释掉问题就没了，说明问题不在它身上。我把整条链路在心里复盘了一遍。我加了个 try-catch，先把异常吞掉，回头再查根因。我把它写进了组内的避坑文档第一章

问题居然复现不了了，这比复现出来更可怕。我把这个内存泄漏的对象引用链打了出来，找到根了。复盘会上我们把它列成了案例

线上日志里出现了从未见过的堆栈，时间戳还是三个月前的。我盯着屏幕沉默了十分钟。我发现问题出在一个我以为永远不会被触发的分支里。同事说这波操作可以写进新人培训教材

同事说他写的代码零 bug，我在 code review 里找到了三个空指针风险。我重新看了一遍手上的计划，把风险项标了出来。我在 devtools 里把这个请求重新发了一次，问题不复现。这大概就是程序员的人生吧

我盯了半天，最后发现是拼写和大小写。我把手上的资料翻出来又读了两遍。我在心里把这个问题的排查过程复盘了一遍，能省半天。幸好之前留了备份