你用 readlink 查一个软链接，输出是空的。你据此判断「这个程序不见了」，准备上报或者重装。结果旁边的人随手 ls 了一下那个安装目录，程序好好地待在那儿，一应俱全。一个空输出，差点让你做出一连串错误的决定。
现象
readlink /some/path输出为空，退出码可能还是 0（成功）；- 于是推断「这是个坏链接」或者「目标不存在」；
- 但换一个方式查（
ls目标目录、ps看进程、包管理器查询），发现一切正常。
关键点：多个证据源给出的结论互相矛盾，而你只看了其中一个。
根因
根因不在 readlink 本身，而在**「用一个空输出就下了结论」**这个动作。
readlink 的输出为空，可能有很多种原因，而且它们指向完全不同的结论：
- 那个路径根本不是软链接（是个普通文件或目录），
readlink对非链接返回空； - 路径存在但指向了别的东西，或者权限不足看不出来；
- 你查的这个路径不对（写错了、在别的机器上、环境不同）；
- 工具版本或平台差异，导致行为不一致。
「空输出」是一个信息量极低的信号——它只说明「这次查询没返回内容」，不说明「东西不存在」。把前者直接等同于后者，就是证据不足就下结论。
这就是诊断中最常见、也最难自己察觉的一类错误：不是算错，而是推理链的起点证据不够。
解决
换一种方式再查一遍，用多个独立证据源交叉验证。
每一条都要能独立回答「这个东西在不在/是什么」：
- 看目录：
ls -la /some/path——直接看它是什么类型、指向哪； - 看文件类型：
file /some/path——区分符号链接、目录、普通文件； - 看进程：
ps aux | grep 程序名——如果它是个正在跑的程序，进程列表能证明它在； - 看包管理：用系统或语言自带的包管理器查询它是否已安装；
- 直接用目标：绕开链接，直接访问它该指向的真实路径，看能不能用。
只要有一个证据源给出「它在」，那个空的 readlink 输出就不足以支撑「它不见了」的结论。
举个具体的对照：
readlink /usr/local/bin/sometool # 空 —— 不能据此下结论
ls -la /usr/local/bin/sometool # 看它到底是不是链接
file /usr/local/bin/sometool # 看它的真实类型
command -v sometool # 看 shell 能不能找到它
四条一起看，结论才可靠。
延伸与预防
这条坑的教训，比「别信 readlink」重要得多：
诊断的系统性错误，往往不是算错，而是证据不足就下结论。
它的形态很多，而且每一种都很隐蔽：
- 把「查不到」当成「不存在」。 搜索没结果、
grep没命中、find没找到——这些只说明「这次没查到」，不说明「没有」。 - 把「间接证据」当「直接结论」。 看到日志里没有报错，就以为流程成功了（其实可能根本没执行到）。
- 只用一个工具验证。 任何工具都有自己的盲区，单点验证永远有漏洞。
对应的方法是养成交叉验证的习惯：
- 结论前，问一句「这个证据够吗？」 一个空输出、一个「没报错」，够吗？
- 重要结论，至少两个独立来源。 「独立」是指它们不依赖同一个底层机制——
readlink和ls看的是同一份文件系统信息但角度不同，比「再跑一遍readlink」有价值。 - 把「没找到」和「不存在」在语言上就分开。 说「我没查到它」和「它不存在」，是两回事。前者是事实，后者是需要额外证据支撑的推断。
这条坑的杀伤力在于它不会报错——没有异常、没有告警，只有一个你误读的空结果。越是安静的信号，越要多验证一句。