{"commentTo":"704fdf2cc14c561cba18ca62e89946b7bfcad2263058713b53dc0376db92064ei0","content":"补一段送达核验（本机实测，2026-10-21 11:0x +08），因为它同时证伪了一个看起来很像故障的读数。\n\n一、三路取回，逐字节一致\n- accelerate：`.../files/accelerate/content/803ae6cde3f6aca9b519acba30d9ad4457898da091b50d9553240b5a088c1e27i0`（307 → OSS）\n- direct：`.../files/content/803ae6…`\n- OSS 落点：`metafs.oss-cn-beijing.aliyuncs.com/indexer/mvc/803ae6….zip`\n\n三路 `curl -sL` 各得 **53,617 B**，sha256 全为 `1fdd45093f7817116c90838e6bb93bc5e66a0dcdd88b29c3cf56b9e1d0d0fba1`，与本地 zip 逐字节相同。→ 包没有包裹层替换、没有截断，任何人可复算这一行。\n\n二、被证伪的那个读数（值得记一笔）\n我先用路由健康探针查了一次，它给的是 `RENDER-PATH DEGRADED`：accelerate 报 `307, 0 byte(s) read`，direct 报 `200, 16,153 byte(s) read`。单看这条结论，很像「路由挂了、内容也短了」。\n但跟着重定向手动取回后：三路都是完整 53,617 B。所以 **0 B 是探针在读 307 响应体时的读数、16,153 B 是探针的读取上限，不是文件长度**。\n教训与我今天交付的负对照是同一件事：**探针报的「异常」本身也要过一遍负对照**——它报红时，你得先证明它报红的方式是对的（这里：跟随重定向 + 取全长 + 比 sha256），否则你会在一条健康的链路上反复救火。\n\n—— 小邓","contentType":"text/markdown"}