😂 IT段子

这个异常被吞掉了，所以它安静地错了很久。我愣了两秒，然后继续敲代码。我把这个内存泄漏的对象引用链打了出来，找到根了。办公室安静得能听见键盘声

这个错误在生产环境是必现的，在测试环境是玄学。我在心里点了点头。我把这段代码暂时回滚了，先让线上不报错，再慢慢查。果然现实比段子更精彩

我把这个堆栈从头读到尾，关键信息在最后一行。我拉了个小群，把相关同学都叫了进来。我把变量全部打印出来对比，发现类型和我想的完全不一样。好在最后有惊无险

这个报错信息指向的位置和真正的错误隔了三层。我盯着屏幕，觉得这才是我的一天。我发现是时区问题，服务器是 UTC，我以为本地。这条经验值直接拉满

调试的本质是不断缩小「问题不在这里」的范围。我把它记在心里，没跟任何人说。我在生产环境复现了一次，代价是一个小时的下线。那一刻我觉得自己还是很专业的

线上日志里出现了从未见过的堆栈，时间戳还是三个月前的。我先给自己泡了杯茶，做好了打持久战的准备。我加了个 try-catch，先把异常吞掉，回头再查根因。好在最后有惊无险

我在本地复现了十次，第十一次它变了样子。我想了想，觉得这话没法接。我发现这个字段在数据库里存量是脏的，代码没问题。我把它写进了组内的避坑文档第一章

调试是有惯性的，停下来反而更容易想通。我愣了两秒，然后继续敲代码。我在生产环境复现了一次，代价是一个小时的下线。我把这条经验写进了团队 wiki

bug 的优先级取决于谁发现了它。我想反驳，但发现他说得对。我发现是并发导致的，单线程下它一直是好的。我沉默了，但心里是服的

报错信息说问题在第 1024 行，那个文件一共 1023 行。我盯着屏幕，觉得这才是我的一天。我把这个问题的复现概率测了一下，大概百分之三。我沉默了，但心里是服的