从 946 号归档箱开始
8 月 22 号下午三点出头，我在机房隔壁那间临时改成工位的储物间里，把编号 946 的归档箱从最下面一层拖出来，箱盖上的封条已经翘边，写着日期的记号笔字迹被手汗蹭花了一半。里面是十七张打印出来的对照图，每张背面都用铅笔标了序号，从 17-01 一直排到 17-17，最早的一张落款是 2025 年 11 月 3 日。那一刻我才明白，「17 图恢复正常使用 946」这个说法之所以在内部传得那么别扭，是因为它把三件不同的事压进了同一个短语里：十七张图、恢复流程、以及 946 这个谁都说不出准确来历的批次号。
说实话，我一开始以为这只是一次例行的素材复原，两个小时能收工。
事情比想象的顽固。权限这一层几乎没有文档，只有两段邮件往来。8 月 24 号上午，负责老系统维护的周允之在电话里跟我说，946 这批图的读取权限当年是挂在三个不同的账号上的，其中一个账号在 2024 年就被并入别的部门，权限没有回收，也没有转移，就那么悬着。他讲得很慢，中间停顿了两次，像是在回忆，又像是在确认自己没记错。我拿笔把三个账号的尾号记在便签上，写到第二个的时候笔没水了，只好换了一支。
恢复不是点一下按钮
真正的麻烦在于顺序。十七张图里有九张依赖同一套缩略图缓存，缓存目录的访问策略和原图目录不一致，如果先动原图，缩略图会全部回退成灰色占位块。这个坑是 8 月 26 号下午踩到的，我按常规流程把前四张图的元数据重建了一遍，结果列表页整屏变成空框，持续了将近四十分钟。周允之的回复只有一句话：「先开 946 批次的白名单，再碰缓存。」
这句话后来被我抄在便签上，贴在显示器边框，一直到今天还没撕。
8 月 29 号，我尝试用另一条入口做交叉验证，也就是同事常提到的「66777浏览器打开」那条老路径。它没有想象中好用，但至少能读到 946 批次的校验记录，帮我确认了十七张图里有三张的校验值其实一直是对的，之前被判为损坏，是因为索引表里多出了一条重复条目。删掉那条多余记录之后，恢复的进度从 62% 直接跳到 94%，剩下 6% 卡在一张 2.7MB 的封面上，原因是文件名里有一个不可见字符。
被忽略的那条记录
我得把这件事说清楚一点：很多人以为「恢复正常使用」是修图本身的问题，其实不是。十七张图的原文件从一开始就没坏，坏的是围绕它们建立的那套索引、缓存和权限关系。9 月 1 号晚上我重新核对了全部十七张图的哈希值，逐条比对归档箱里的打印件，确认恢复后的一致率是 100%，但这也意味着过去十个月里，凡是引用过 946 批次的地方，显示的很可能都是缓存出来的旧版本，而不是原图。这个结论让我在椅子上坐了很久没有说话。
我的观点可能不太讨喜：这套系统当初就不该把权限、缓存、索引绑在同一条链上，出问题是迟早的事，946 只是恰好第一批发作。
9 月 2 号上午十点，我把最终报告发给周允之，附件里是十七张图的恢复对照表、三份权限变更记录和一份时间线。他回了一句「收到，辛苦了」，没有别的。我关掉窗口，端起已经凉透的茶，忽然觉得这十一天像是走完了一段很长、很安静的路，路上没有观众，只有十七个编号和一堆需要说清楚的因果。