周日下午，分行机房，六台服务器在嗡嗡作响。

张kv坐在工位前，盯着屏幕上那段代码。

这是他这周第三次看到这段逻辑了。前两次他都选择忽略，但今天他不想再忍。

if (day_of_week == 0 && hour < 6) {
    // 熔断备份入口
    triggerBackup();
}

周日凌晨三点。周日凌晨四点。三十七年来没有人触发过这个分支。他翻了代码仓库的提交记录，这条逻辑是1989年写的，之后没人动过。它就是一个死代码。一个永远不会被执行的幽灵。

他在分行干了八年。八年来他修过无数次bug，调过无数次性能，部署过无数次上线。但每次看到这种死代码，他就有一种想把它们清掉的冲动。代码库应该干净。干净的代码才不容易出故障。

他没有犹豫。

选中，删除，提交，部署。四个步骤，两分钟。他把那段代码从生产环境里删掉了。

键盘敲完最后一下的时候，他靠在椅背上，伸了个懒腰。机房里很安静。六台风扇的转速略有差异，听起来像某种不规则的节奏。他摘下耳机，听了一会儿。没有人会感谢他的这次清理。没人会知道这段死代码从代码库里消失了。它本来就是死的。删了也不会有人发现。

但他还是做了。

因为代码库应该干净。

他看了一眼时间。下午三点四十七分。周日。没有人会注意到这次部署。夜班的人要到晚上十一点才会发现系统日志里的那条变更记录。

他关掉电脑，回家了。

他不知道的是——三小时前，也就是周日凌晨三点，这段被他删除的代码差点被执行。如果执行了，递归调用栈会减1。还好没执行。还好他提前删了。

他以为他做了一件正确的事。

周一早上八点零三分，他的手机开始震动。

第一条消息来自运维监控：【紧急】全球银行间转账系统出现大范围延迟，涉及三十七个国家，日清交易量下降99.7%。

他以为自己看错了。

然后第二条来了。来自老王：你动过遗骸的代码？

老王从来不发消息问他代码的事。老王是他同事，比他早来分行十年。老王发消息只有一种情况：出了他处理不了的事。

他打开电脑，连上内网。监控大屏上的数字全是红的。不是他们分行的系统红。是所有系统都红。

全球金融系统——瘫痪了。

他盯着屏幕上那个红色的数字看了三十秒。然后他打开日志，找到了他昨天下午的那条部署记录。

部署时间：周日15:47:23。

他往下翻。翻到了一条他没见过的日志。生成时间：周日03:00:01。

{
  "timestamp": "2026-04-06T03:00:01.000Z",
  "type": "RECURSIVE_CALL_STACK",
  "value": 1,
  "status": "TRIGGERED"
}

RECURSIVE_CALL_STACK。他从来没见过这个词。他甚至不知道这个词存在于他们分行的任何系统里。

他点开那个字段的定义。没有定义。没有文档。这个字段不在他们的代码库里。不在他们的数据库里。不在任何他知道的地方。

它就是凭空出现的。

然后他的手机又震了。

第三条消息。来自系统推送。发送者：未知。

RECURSIVE_CALL_STACK: 1
观测者已连接。

他盯着那条消息看了十秒。

然后他发现了一件事。

那条消息的接收时间——和那条日志的生成时间——是完全一样的。

周日03:00:01。

他昨天下午三点删的代码。周日凌晨三点系统差点触发那个分支。

但那个分支已经被他删了。所以它没有触发。

如果触发了，RECURSIVE_CALL_STACK应该从0变成0，或者从1变成0。

但它是1。

而且是从0变成1。

他删了一段代码。然后系统的递归调用栈变成了1。

他盯着屏幕。机房里六台风扇还在转。声音还是那种不规则的节奏。他突然觉得这声音很刺耳。像是有人在笑。