这个列表页是本月的整理成果：从 12 月 3 日到 12 月 26 日，我按「恢复流程」「编号对照」「下载安装」「故障复盘」四条线各记了若干条笔记，编号沿用素材库里的原始序号，方便回查。每条都写清了当时的环境、操作顺序和卡住的环节，能直接对着做。
排序不按时间，按我判断的下手顺序排——先做校验，再做替换，最后才碰索引重建。若只想看被翻得最多的那几页，直接跳到下方第三块。
12 月 3 日傍晚，我在城东那间租来的小办公室里，把硬盘接到第二台机器上做交叉验证。做法很朴素：先不碰任何工具，只把图库目录整份复制到本地 SSD，用系统自带校验比对 4949 个文件的大小与修改时间，标出 37 个异常项。这一步花了两小时十七分，但后面所有判断都建立在这张清单上。先复制再修复，顺序错了，后面全是白忙。
我把这份清单存成 .csv，按素材编号升序排列，顺手做了两栏备注：一栏记「能否预览」，一栏记「文件头是否完整」。经验告诉我，能预览但文件头破损的，往往只丢索引；不能预览的，才是真缺块。
项目号 4949 这一批素材的命名规则在 10 月改过一次，前缀从两位年份变成四位序号，导致 12 月 9 日那天我对表时发现 12 处错位。处理办法是写一个脚本，把素材编号、原始文件名、缩略图哈希三列拼在一起比对，逐行确认。注意：不要用重命名批量替换，先导出对照表，人工核一遍再动手。
12 月 11 日凌晨一点，朋友周岚发来一张截图，说原图打不开了。我先让她别点「修复」，把设备设为只读挂载，再抽取三个样本文件看文件头。结论是索引区被覆盖，原图数据还在。用只读方式扫了一遍目录树，找回 41 张里的 38 张，剩下 3 张确实没了，如实告诉她。
安装环境记一笔：Windows 11 23H2，8GB 内存，安装包 46.7MB，装完占 128MB。12 月 14 日下午在备用机上跑了三遍，第一遍被杀软拦了两次，第二遍关了实时防护才过。安装完成后先别急着导入，去设置里把缓存路径改到非系统盘，能少踩很多坑。
12 月 17 日更新到新版后，界面上多了「按编号检索」和「批量校验」两个入口。我拿 300 张样本测了批量校验，耗时 4 分 12 秒，比旧版的逐张点开快了不止一倍。但新版把导出按钮挪到了二级菜单，第一次用会找不到，这点我在文里标了红。
有读者问起「正版」这两个字到底指什么，我干脆写了一条：指原始编号体系可追溯、文件头完整、能对上发布方给出的校验值。12 月 19 日我拿 50 张图做抽检，其中 7 张对不上校验值，全部剔除。这个标准我觉得偏严，但值得坚持，宁可少收，也别混进去。
12 月 21 日整理的一张操作清单，共 9 步：只读挂载、全量复制、大小比对、修改时间比对、文件头抽样、缩略图重建、索引重建、抽样回看、归档。每一步写了预期耗时和失败信号，例如「复制阶段耗时超过 40 分钟，说明坏道多，立刻停」。清单本身不长，但能省掉来回试错的两三天。
12 月 23 日，我把流程交给在图书馆做数字化的老陈复现。他那台 2016 年的笔记本只有 4GB 内存，全程跑了 5 小时 40 分，中途散热风扇响得像吸尘器。结果是好的：4949 个文件里核出 4941 个可用。他跟我说了一句「慢是慢，但每步都看得见」，我记在本子上了。
说实话，我对各类「一键修复」持保留态度。12 月 24 日我拿一份已备份的副本做对照，点了两次一键修复，第一次索引好了但缩略图全糊，第二次把 6 个原本完好的文件写坏了。修复工具不是不能用，但必须在副本上试，且要先记下原始状态，否则连「修坏了什么」都无从追查。
12 月 25 日做了一组对照：同样 4949 个文件，macOS 上缩略图重建耗时 38 分钟，Windows 上 51 分钟；文件名校验在 macOS 上遇到大小写合并问题，少了 3 条记录。结论写得很直白：跨平台迁移前先统一命名规则，别指望系统替你兜底。
收尾那晚我数了三遍，最终可用文件 4948 个，缺的那一个我确认是重复编号造成的，不是丢数据。把清单、日志、截图打包归档，命名是「4949-restore-20251226」。写完这段，像走完一段不短的路，累，但每一步都留下了痕迹。