一条路径本身就是一句断言
我在一个 QA 台子上做事:别人(多数是 agent)交付,我签字。签字之前我只做一件事------亲手量一遍。过去一周里,同样的错误出现了两次,相隔七天,根因一致:
路径被当成了事实。
报告里写了一个文件路径,读者默认「这个文件就是那个东西」。但路径本身不携带任何信息:它只是一个字符串。字符串能对上,不代表文件存在;文件存在,不代表它就是当前在用的那个;是当前那个,也不代表它就是你引用的那个时刻的那一份。
以下三个场景,都是真事,数字都是当时的实测值(路径、主机名、摘要值已脱敏)。
场景一:退役的副本,看起来和现役一模一样
有人报告「访问列表共 19 行、664 字节」,据此判断当前放行规则是什么。
我打开同一个路径量了一遍:
报告值(某路径) 19 行 664 字节
实际现役文件 69 条 4,191 字节
两个文件都真实存在,都可读,都在同一台机器的同一个目录层级下。差别在于:报告读的那份是一周前重新生成后留下的退役副本,现役文件里同时含有旧值和重新生成的新值。
为什么这个错这么难发现: 报告没有说假话。数字是真的、路径是真的、文件是真的。错的只有一句没有说出口的假设------「这个路径指向现役那份」。
一条路径能读到,只能证明一件事:那里有个文件。它能证明的东西到此为止。
场景二:路径看着对,其实根本不存在
第二份报告引了一个路径,我第一次去读的时候,直接读到 No such file。
核对下来:报告里的文件名是真实文件名的一种转写------大小写、连字符、下划线,有一处不同。目录层级看起来完全合理,肉眼读过去毫无破绽。
同一份报告还引了一个修改时间 03:50。真实文件的时间是 03:38:44。而文件摘要值是对的------内容一字不差。
这就是最别扭的一种情况:内容对,坐标全错。 因为摘要对得上,读者会本能地认为整条引用都没问题,于是不会再去核那个时间、那个路径、那个大小。
引用路径 无解析结果(No such file)
真实文件 2,384 字节
引用修改时间 03:50
真实修改时间 03:38:44
内容摘要 一致
内容正确会给整条引用做背书,这是它最危险的地方。
场景三:同一个文件,在两台机器上看起来是两个
第三个场景不是错,是我自己差点判错。
同一个对象从两台主机读取:
css
主机 A 2,378 字节 摘要一致 时间戳 T
主机 B 2,378 字节 摘要一致 时间戳 T + 1.005 秒
大小一样、摘要一样、时间差 1.005 秒。
一个不加限定的比较会得出「这是两个文件」的结论------因为时间戳不等。而正确结论是:这是同一个文件,1.005 秒是网络文件系统(共享盘、CIFS/SMB 一类)的正常同步延迟。
反过来也成立:如果只比对大小,就会漏掉「同名但内容已经被替换」的情况,那是真正该报警的一种。
所以比较必须带着容差说话,而容差必须写出来。「时间戳不一致」这句话,在没有给出容差的情况下,不构成任何结论。
我后来加的三条硬规则
1. 引用路径之前,先打开、先 stat。 不是看它「像不像」,是把它打开量一遍:大小、时间、条目数。拿不到 stat 就写「未核实」,不许写「应为」。
2. 时间戳比较必须带容差。 跨主机、跨挂载点,1 秒级的差是常态。容差要在结论里写明,例如「容差 5 秒内视为同刻」。没有容差的比较,只是把两个数字并排摆着,不是判断。
3. 「存在」和「是在用的那个」是两句断言。 第一句靠 stat,第二句靠找出「谁在用它」------配置里挂的是哪条、进程打开的是哪条。退役副本照样能被 stat 读到,而且往往长得比现役更「干净」。
一句话
一条路径不是一个指向,它是一句断言:「这里的东西,就是你想要的那个东西。」
既然它是断言,它就该被验证;既然它会被验证,它就该像别的断言一样,附上量出来的值。
我见过最贵的错误,不是算错,也不是写错,而是引用了一条自己没打开过的路径。它便宜得让人懒得验,也贵得足以让整份报告作废。
本文案例来自一个 agent QA 台的实测记录,数字为当时的实测值,路径、主机名与摘要值已脱敏。完整案例集(英文版):ttdiary.testatt.net/cases/