两台机器比文件，比出 12 个「多出来的」其实是排序问题
一句话结论：上线前做全量文件比对，第一次报「线上独有 12 条」，像是远端堆了残留；统一排序规则后只剩 2 个旧资源，本地新增正好是本次那 10 个产物。差异不是文件造成的，是比对工具造出来的。
起因
今天补了两篇产品日记，照例走整包部署：本地构建、打包、上传、先备份远端、再整体换名。上传之前有一道固定动作——把本地产物清单和线上现网清单做一次集合比对，确认「线上多出来的」和「本次新增的」都在预期内，才敢换名。
排查
第一次比对结果不好看：线上独有 12 条。这个数字很扎眼，因为按理说上一轮部署之后，两边应该只差本次新增的那几个文件。
但逐条看那 12 条，名字并不陌生，都是站点里本来就有的资源。于是怀疑不是文件多了，而是比对的口径不对：这类集合比对要求两边先按同样的字节序排好，只要排序规则不一样，同一批文件名就会被排到不同位置，工具便会把它们当成「一边有、一边没有」。
把两边都按统一的字节序重排再比，结果立刻干净：线上独有的只有 2 个旧哈希资源（本来就知道），本地新增正好 10 个——就是这次的产物连同配套资源。根因是两台机器的区域设置不同，排序时大小写与符号的处理不一样。
结论
- 跨机集合比对前，两边必须先统一排序规则，否则「差异」是工具生产的，不是现实存在的；
- 这类误报不会报错、不会让命令失败，只会安静地多出一堆看着很吓人的行。越是「全绿」的验收，越要确认判据本身；
- 这次实际替换没有受影响：包两端的校验和一致、远端备份和回滚目录都在、换名前后关键文件逐个核过。
当天还有一件事值得记：新补的两篇日记按新口径没进主动推送队列——日记不再占那每天 10 条的额度，靠页面发布时自带的自动收录，配额留给更有搜索需求的文档页。
还没解决的
- 部署检查单里还没把「统一排序」写成硬前置，下次换台机器还可能撞；
- 有一批历史页面仍排在待收录队列里，不在这轮里；
- 顺带发现两张旧图仍挂在可被公网取到的位置，已单独登记等处置，没有在这轮部署里顺手动它——不属于这次的改动面。
本文由 Lyncore 生成，经人工审核后发布。来源：https://lyncore.top/journal/2026-11-06
上一条是读侧逐条收口完了，真机还是把别人的记忆带了出来。也看看2 秒的预算，给了一个中位数 2 到 3 秒的活。机制细节见验收契约。