老周的 T480：2417 行索引对不上 8930 行备份
5 月 29 日凌晨 2 点 41 分强制关机，表在第 2418 行断开。先别恢复，先比对。
上周四晚上十点零七分，朋友老周把他的 ThinkPad T480 抱到我家桌上，说 49 图库那套资料打不开了，索引页全部指向空节点。屏幕上那张表只有 2,417 行，而备份文件本该有 8,930 行。
我没有立刻动手。先做了一件事：把原始文件整体复制到一块移动硬盘，标记为 bundle_raw_0601。这个动作花了四分钟，但后来救了我一次。
恢复49图库资料步骤的核心不是"找回文件"，而是"判断哪一层坏了"。老周的问题出在索引层，文件本体其实都在。
第一步：确认损坏范围，而不是马上恢复
我用 md5sum 对比了原始目录和 5 月 28 日的快照，发现 62 个文件里只有 1 个索引文件不匹配，其余 61 个哈希完全一致。这就排除了批量误删的可能。
表里第 2418 行之后的内容全部丢失，恰好卡在一次强制关机的时间点：5 月 29 日凌晨 2 点 41 分。老周说那晚他在下载一个 1.8GB 的图包，进度条卡在 73%。
这里可以对照 精准49图库更新 里提到的增量校验思路，它把"完整重建"换成了"补齐缺口"，速度快得多。
第二步：从缓存目录里捞回索引碎片
大多数图库工具会在本地留一份临时索引，位置通常在 ~/.cache/gallery/index_tmp 之类的地方。老周这台机器上，我确实找到了一个 47KB 的残片。
残片不完整，但能读出 3,106 条记录的键名。把它们和现有 2,417 行做并集，覆盖率一下升到 61.9%。这一步我没有用脚本自动化，手工核对了前 200 行。
如果你也在处理类似问题，管家婆论坛资料图库 那篇帖子里有一段关于缓存命名规则的讨论，解释得比我清楚。
第三步：重建缺失节点并回填
剩下的 3,407 条记录要靠回填。我写了一个四十几行的脚本，按文件哈希去匹配目录里的实际文件，命中 3,289 条。剩下 118 条确实不存在，判断为当初就没下载完。
回填完成后，我让老周自己点开随机 20 个条目逐个验证。他点到第 6 个时说了句"这个封面我记得，是绿色的那张"，那一下我才算松了口气。
说句可能不太合群的话：我认为恢复49图库资料步骤里被严重高估的是"工具"，被严重低估的是"备份时点记录"。老周如果记下了 5 月 29 日凌晨那次关机，整个排查能省掉一半时间。多数人把恢复当成技术活，其实它是记录活。
第四步：验证与固化
修好的索引我另存为 index_fixed_v2，并在文件头写入恢复时间 2026-06-01 22:53。这个习惯来自一次教训：三年前我修好一张表，半年后再出问题，没人分得清哪份是修过的。
关于访问层的处理，恢复49图库访问 里有一节讲浏览器侧缓存清理，补上了我这套流程缺的最后一块。另外 最新版图库 的目录结构说明也值得先读一遍再动手。
如果你遇到的是入口被拦而不是数据损坏，可以看 qq浏览器网站免费入口关闭 里的排查顺序，那是另一类问题，别混在一起处理。
三条可复现的操作要点
- 动手前完整复制原始目录，命名带日期，绝不在原文件上直接改。
- 先用哈希比对确认损坏层，索引坏了不代表文件坏了，这一点决定了后续所有工作量。
- 回填后必须人工抽检，抽检样本不少于 20 条，且要让不熟悉数据结构的人来点。
老周走的时候是晚上十一点半，他把 T480 合上，说了一句"早知道先备份"。我没接话，因为这句话我听过太多次，包括从我自己嘴里。