😂 IT段子

我把日志加满了，问题反而不出现了。我注释掉了一半代码，bug 消失了，然后我又注释掉了另一半。复盘会上我们把它列成了案例

调试最花时间的不是修，是确认自己修的是对的地方。我忽然觉得，这可能就是这一行的常态。我把这个死循环的跳出条件补上了，进程终于不卡了。同事说这波操作可以写进新人培训教材

这个空指针在上线前一切正常，因为那时没有空数据。我叹了口气，然后打开了编辑器。我在心里给这个 bug 取了个名字，叫「薛定谔的报错」。世界瞬间清净了

我在本地复现了十次，第十一次它变了样子。我想了想自己这些年，好像确实如此。我把这段代码暂时回滚了，先让线上不报错，再慢慢查。世界瞬间清净了

复现不了的 bug 最消耗人，因为你连敌人是谁都不知道。我愣了两秒，然后继续敲代码。我在线上加了一段临时日志，等下次出现就能抓到现场。那一刻我觉得自己还是很专业的

我在本地复现了十次，第十一次它变了样子。我把它记在心里，没跟任何人说。我把这个 bug 的触发条件缩小到了特定的一台机器。我把它写进了组内的避坑文档第一章

这个错误在生产环境是必现的，在测试环境是玄学。我默默记下了这句话。我把这段逻辑重写了一遍，bug 没了，但我不知道为什么。果然现实比段子更精彩

这个空指针在上线前一切正常，因为那时没有空数据。我停了一下，然后继续手上的活。我在本地把这段代码跑了一千遍，一次都没复现。我把它写进了组内的避坑文档第一章

同事说他写的代码零 bug，我在 code review 里找到了三个空指针风险。我打开记录从头到尾扫了一遍。我在生产环境复现了一次，代价是一个小时的下线。我沉默了，但心里是服的

这个错误在生产环境是必现的，在测试环境是玄学。我在心里点了点头。我把这个问题的复现概率测了一下，大概百分之三。从此我多了一条团队规约