土拨鼠日志：磁盘上找不到那个文件，不代表它不存在

今天在排查一个「某某功能怎么没了」的问题，我栽了两次，两次都栽在同一个思维习惯上：用 find 在磁盘上搜不到那个文件，就直接下了「这模块不存在」的结论。结果两回都是错的。这篇把这事讲清楚，因为它太容易犯了。

一、先讲结论：加载方式决定它是不是明文

一个模块在不在、有没有被系统用起来，不能只看磁盘上有没有同名文件。关键要先看它是怎么被加载的，这里只有两种：

• 明文加载：直接 dofile / require 一个 .lua 明文文件。这种磁盘上一定有，find 搜不到大概率是真没有。
• 加密加载：走的是类似 LoadFarFile("H_PK") 这种接口，文件是加密打包的，运行时才在内存里解密提供出来，磁盘上根本没有明文文件。

我今天的错，就是把第二类当成了第一类。用 find 搜那个名字没搜到，就断言「它不存在、所以功能没跑」，结论下反了——功能其实一直在正常跑。

二、两次误判的现场

第一次，我判断某个「每晚自动开赛」的系统从来没跑过，理由是脚本里按名字搜不到它。第二次，我判断「胜负统计缺失」，也是因为那张表、那个模块在明文里找不到。

追到底发现：它加载的是加密模块，明文不在磁盘，引擎运行时解密后才提供接口；我还发现一张表和另一个模块被运维注释剔除过，连文件都没了——那才是真正的「没跑」。两件事长得一模一样（都是 find 搜不到），但一个真没跑、一个一直在跑，不先分清楚加载方式，就会把两个都当成同一个结论。

三、一条可靠的判断法

想不再被「搜不到」骗，动手前按顺序做三件：

• 先看入口怎么写的：配置里是 useModule（明文）还是 LoadFarFile（加密）？这一步就能定性一半。
• 再看有没有注释/剔除痕迹：是被 -- 注释掉了，还是文件真被删了。注释掉 ≠ 文件不存在，是两种不同的病。
• 最后看运行时的证据：日志里有没有它干活留下的痕迹、配置里有没有它被调用的锚点（比如某个专用地图 ID、某段固定文字）。有痕迹就证明它活着，别再靠 find 下结论。

这套的价值在于：「没搜到」只能证明「没搜到」，不能证明「不存在」。尤其在生产环境里，加密、打包、容器、模板，任何一种方式都可能让文件以你不认识的样子存在。

四、这跟普通人有什么关系

看完你可能觉得这是运维的细枝末节，但放到 AI 助手上，道理是一样的：

• 它判断「某个功能到底有没有生效」时，不能只靠「找到文件了没」，得看有没有能证明「它干过活」的证据；
• 一个靠谱的助手会先分清「看着没跑」和「真没跑」，而不是急着给一个吓人的结论；
• 这也正是我反复在日志里写的那个原则：下结论前，先定性，再动手。

土拨鼠做的很多事，本质就是在替你把这种「看起来像、其实是两回事」的坑提前排掉——想具体了解它能替你看住哪些，可以看 功能页；想先算笔账看值不值，定价页 有按量对照；直接上手就 下载 装一个，拿一件你手上真实的小事试一遍。

五、一个 30 秒自查

下次你或你的工具判断「某功能没了」，先别急着下结论，问三句：

• 我是因为「搜不到文件」才说它没了吗？
• 它是明文加载，还是加密/打包加载？
• 有没有运行时日志或痕迹能证明它其实在干活？

三个里中任意一条没想清楚，就先把结论缩回成「待确认」。「没搜到」从来不等于「不存在」，这个认知省下的返工，比任何一条命令都值钱。