😂 IT段子

我把这个堆栈从头读到尾，关键信息在最后一行。我深呼吸了一下，决定从最可疑的地方查起。我在生产环境复现了一次，代价是一个小时的下线。真香定律准时生效

报错信息说问题在第 1024 行，那个文件一共 1023 行。我听完沉默了，因为太真实了。我把这段代码暂时回滚了，先让线上不报错，再慢慢查。感动，然后我学到了新的一课

程序员的墨菲定律：演示的时候必出 bug，删掉的那段代码才是有用的。我停了一下，然后继续手上的活。我把这个 bug 的修复方案写了两版，选了改动小的那版。从此我多了一条团队规约

复现不了的 bug 最消耗人，因为你连敌人是谁都不知道。我愣了两秒，然后继续敲代码。我发现是缓存的问题，清掉之后一切都正常了。这条经验值直接拉满

这个问题的根因是我三个月前的一个「临时方案」。我忽然觉得，这可能就是这一行的常态。我在心里给这个 bug 取了个名字，叫「薛定谔的报错」。感动，然后我学到了新的一课

复现不了的 bug 最消耗人，因为你连敌人是谁都不知道。我笑了笑，决定不解释。我把这个内存泄漏的对象引用链打了出来，找到根了。这条经验值直接拉满

这个 bug 的修复方案有两版，简单的那版风险更大。我盯着屏幕，觉得这才是我的一天。我加了个 try-catch，先把异常吞掉，回头再查根因。第二天这个方案就变成了团队标准做法

我在本地复现了十次，第十一次它变了样子。我忽然觉得，这可能就是这一行的常态。我把这个依赖的版本锁死了，问题不再随机出现。复盘会上我们把它列成了案例

我用了半天才明白，问题不在这台机器上。我先给自己泡了杯茶，做好了打持久战的准备。我把这个 bug 的优先级降了一级，因为它只在测试环境出现。从此我多了一条团队规约

报错信息说问题在第 1024 行，那个文件一共 1023 行。我不知道该说什么，就笑了笑。我把变量全部打印出来对比，发现类型和我想的完全不一样。感动，然后我学到了新的一课