小吴递来热可可：现在怎么办？要回滚整个优化版本吗？那样所有用户的交易延迟都会涨30%。
林深没有回答。他调出分布式事务日志，开始逐条比对异常交易的上下文。凌晨四点零九分，他的手指停在某个TraceID上：找到了！异常不是因为队列空，是因为消费线程提前终止了。
监控屏的光映在他脸上，看这个线程状态，它在处理到第三十二个请求时，触发了JVM的垃圾回收，导致线程被暂停。后面的请求继续往队列里塞数据，等线程恢复时，队列头部的对象已经被GC回收了。
这不是他最初设想的边界条件，却是异常最擅长的伪装——总是以最意想不到的方式，在最不可能的时刻撕开系统的裂缝。
需要重新设计队列的消费确认机制。他快速敲击键盘，每个消息处理完必须发送ACK，否则触发重试。另外，给余额缓存加个版本号，每次更新都校验版本，避免读到脏数据。
晨光透过百叶窗渗进来时，最后一条异常日志终于停止滚动。小吴盯着恢复正常的监控面板，长舒一口气：深哥，你好像知道问题会出在这儿。
林深揉了揉发酸的后颈，看向窗外泛白的天空：不是知道，是每个异常都应该被认真对待。他打开代码提交记录，三年前我师父退休时说过，异常日志不是麻烦，是系统在给你发求救信号。那时候我觉得他太保守，现在才明白...
他点击提交，将新的异常处理逻辑推送到预发布环境：我们写的不是代码，是别人生活的保障。
上午十点，银行总部的通报会上，林深站在投影屏前。屏幕上是他重新设计的异常处理流程图，每个节点都标注着详细的处理策略。
这次事件暴露的不仅是一个代码漏洞。他说，更是我们对小概率异常的傲慢。从今天起，所有核心交易模块的异常处理必须包含三级降级策略，并且每月进行异常注入测试。
散会后，小吴抱着笔记本追出来：深哥，刚才运维说回滚的资金都补回来了，用户没损失。
林深笑了笑，递给他一杯热咖啡：记住，写代码时多留的那行异常处理，可能就是某天深夜，帮你挡住雪崩的那根绳子。
窗外，秋日的阳光正漫过城市楼群。某个ATM机前，老人取出养老金，核对余额后露出笑容。那串数字背后，是无数个像林深这样的程序员，在异常日志的迷宫里，固执地点亮每一盏灯。