一个预料中的红色，藏着一个在读空目录的探针
来源：dev.to — 2026-09-05
📋 概述
作者项目覆盖率表里有一行长期显示 0/13、后来变 0/19，整整一天每次 commit 他都会看到它却从不驻足——因为零正是他预期中的数字，那项工作本就未完成，红色对未完成工作不算新闻。直到一次审计，问题才水落石出：那行测量的其实是什么都没有。负责该项检查的 crate 里写死了路径常量，却被错误地相对仓库根目录解析——它指向的目录根本不在仓库里而是仓库的兄弟目录，于是读取器打开一个不存在的路径、找不到任何文件，对一个空集诚实地做了算术：十三分之零。后来有人加了 crate 分母升到 19，看起来更像「项目在缓慢进步」，而真正的失败模式被无声吞掉。
🔑 核心要点
- 真正埋雷的是那条路径常量被相对仓库根解析，指向的却是仓库外的兄弟目录：读取器打开不存在的路径、找不到文件，对一个空集诚实地报出 0/13
- 它会逃过审计是因为旁边两行也确实为正当原因红着（文件台账 0/289、文档普查 0/1916）：一个预期的红藏在一行预期红之中，审计只问数字有没有在动、没问探针能不能产生非零数字
- 修复不是改路径一行那么简单，关键是补上了正向对照测试：指向空目录必须读 0/n、含一张图必须读 1/n、指真目录就读出磁盘实有数量——永远报 0 与永远报 n/n 从此成为两种看得见的失败
- 分母不再手抄而改从 Cargo.toml 的 workspace 成员推导：新增 crate 自动抬高分母，因为「我用手维护的分母，是那个会附和我自己的分母」
- 作者自省补课：他写过「每个检查都要有植入的负例」，却从没为反方向设规则——植入的负例只能证明检查会失败，植入的正例才能证明它能成功；他以前只建了配对的一半却管它叫纪律
💡 金句
我把红色读成关于项目的一句陈述，而它其实是关于读者的陈述——这跟我曾写过又显然没内化的那个形状一样：把一个空的搜索结果读成「不存在」。
👍 0
👎 0
← 返回 dev.to 首页