土拨鼠日志：代码删了不代表真修了，得让它在运行时不报错

今天改了一个游戏后台里的假人 NPC 模块，它一直在刷同一种报错。一开始我们以为把触发报错的那几行删了就完事了，后来才意识到：删掉代码只是静态结论，离「真修好」还差一场运行时的证明。今天这篇就把这个坑和它的解法摊开讲。

一、删了代码，凭什么说它不会再报

很多排查会停在「找到了那行、删掉了」这一步。但真正的问题是：你怎么证明删完之后，运行起来真的不再触发？

删代码只回答了「源码里没了这段逻辑」，没回答「程序跑起来不再走坏路径」。尤其是那种带兜底、带守卫、带热载的模块，你删的这段可能不是唯一触发点，也可能删的位置根本不在真正执行的路径上。

所以我们这次的做法是：不靠眼睛，靠实测。搭一个隔离的测试环境，把这个模块的函数单独拉出来跑一遍，数一数那个会报错的调用到底被触发了几次。

二、隔离测试台：让「删了」变成「不再报」

具体做法比想象中简单。那个模块要调一堆引擎接口（取数据、改形象、喊话之类），我们在测试环境里把这些接口用一个替身（stub）包一层，每次被调用就记一笔。

然后分别用「改之前」和「改之后」两份代码，跑同一个函数：

• 改之前：那个会刷报错的接口被调用了 2 次——这就是报错在运行时的根源；
• 改之后：同一个接口被调用 0 次，而它真正该干的「换装」动作一次不少，照常执行；

这一下，结论就从「我删了那块代码」升级成「这个函数在真实调用路径上，已经不再碰那个会报错的接口，且核心功能未受影响」。这才是能交差的证据。

三、一个伪守卫：它只查有没有，不查在不在

排查到一半，我们还挖出一个很隐蔽的坑：模块里原本写了个「守卫」函数，本意是「先确认对象还有效，再往下走」，结果这个守卫只检查了索引是不是空、是不是零，根本没查这个对象到底存不存在。

于是对着一堆已经不存在的空索引，守卫照样放行，后面的接口一调就报错。这个坑的教训是：

• 「存在性」要用真的判活接口去查，不能用一个「只查序号」的假守卫糊弄过去；
• 加守卫之前先想清楚：你要防的是「序号为空」还是「对象已死」，这是两个完全不同的东西。

四、这套东西在土拨鼠里长什么样

说点能直接对应上的：

• 改完任何东西，土拨鼠都会走一道发布前闸，能扫出来的暴露点动手前就拦住，不靠「我觉得没事」；
• 它不会用「做完了」这句话糊弄你，而是拿机器证据说话——跑了什么、过了几项、还差什么，一眼看得到；
• 像今天这种「删了不等于修了」的排查，它会先做运行时的复验再下结论，而不是停在改代码那一刻。

如果你也在被这类「改了却还是报错」的事折磨，可以先看 功能页 里验收与发布闸的部分；想算清它值不值，定价页 有按量账本；真要上手指南，下载 装一个，拿你手头那个一直在报错的脚本试着让 AI 复验一遍，比读十篇攻略管用。

五、一个 30 秒自查

下次你对某段代码说「修好了」之前，按顺序问三句：

• 我删的是不是真正被执行的那条路径？
• 有没有一个守卫在「假装检查」，其实只查了序号、没查对象还在不在？
• 有没有在运行层面证明它不再触发，而不只是「源码里没了」？

三句里中一句，都说明你还没到能说「修好」的时候。真正的修好，是让它在运行时安静下来。