先说清楚我为什么会对这件事这么较真。去年十一月，我把四十九个图库分卷目录从工作盘迁移到一块二手三星 870 EVO 上，容量 1TB，迁移完成日期是 11 月 18 日，校验通过的文件是 37,412 个，缺失 6 个，我当时用记事本记下了这六个文件名，准备第二天补。第二天我没有补。三个月后，同事周敏在群里问起“那份带缩略图的清单还在不在”，我才重新打开那块盘，发现客户端扫出来的索引是 0，缓存目录 `/Users/jiangwan/Library/Caches/gallery49/index` 里只剩下一个 4KB 的 lock 文件，时间戳停在 11 月 18 日 23:07。这就是“49k图库资料库免费版资源恢复”这件事的起点，一个被自己的拖延症埋下的坑，而不是什么宏大的技术命题。
我先把能想到的路径都试了一遍：客户端自带的“重建索引”按钮点了四次，每次进度条走到 12% 就停住；手动删除 lock 文件后重启，弹出一行 `ERR_INDEX_MISMATCH`，错误码后面跟着的哈希值和我在 11 月 18 日备份的清单哈希对不上。这时候我才意识到，问题不在客户端，而在我当时迁移时用的那个同步脚本——它把索引文件的修改时间写成了未来时间，客户端认为索引“过期且不可信”，于是直接丢弃。恢复的第一步不是找资源，而是让客户端重新相信那份索引。这一点，我在后来的日志里写了三遍，怕自己忘了。如果你只是想弄清楚客户端本身的安装问题，那属于另一条线，可以先看 tk49正版下载安装 那篇，我这里只谈数据。
需要提醒：我下面写的所有路径、错误码、时间戳，都来自我本机的一次真实操作记录，不构成任何通用方案。不同版本客户端的索引结构差异很大，照抄有风险。
线索 01
周敏是隔壁组做数据校验的，她习惯每周日晚上十点导出一份 CSV 清单，文件名带日期。11 月 19 日那份我一直没删，存在微信文件助手里，大小 2.8MB。把它和客户端重建后的索引逐行对比，是我做的第一件事，方法很笨：用 `diff` 跑了两遍，第一遍按文件名排序，第二遍按哈希排序，第二遍才跑出结果——有 214 条记录的路径指向一个已经改名的上级目录。也就是说，索引并没有“丢”，它只是记着旧地址。
2025-11-19对比 2.8MB
线索 02
路径批量替换这件事，我一开始想用脚本，写到一半被自己叫停，因为 214 条里有 9 条同时匹配两个上级目录，脚本会改错。最后我是在文本编辑器里手动过的，一条一条改，改了大概四十分钟，中间接了杯咖啡。改完存盘前我把原文件另存为 `.bak`，这个习惯救了我——第一次替换后客户端直接崩溃，靠 `.bak` 回滚回来，发现是我多改了一行头部声明。
手动修改 214 条备份 1 份
线索 03
去年修手机浏览器缓存问题时，我发现一个规律：很多“索引丢失”本质上是缓存目录权限被系统回收了。桌面端也一样。我盯着那个 4KB 的 lock 文件看了很久，最后用 `ls -la` 逐层往上查，果然在上一级目录发现权限变成了 `drwxr-xr-x` 而不是原来的 `drwxrwx---`，写权限没了，客户端当然写不进新索引。这个发现比路径替换更关键，因为它解释了为什么重建索引总在 12% 卡住。
权限位对比卡在 12%
线索 04
客户端日志里有一行让我困惑了很久的记录，内容是某个被截断的地址加上一串无意义字符，看起来像用户输入错误拼写。我对照了三次日志时间，发现它出现在每次重建索引失败前的 0.3 秒。后来我判断这是客户端把内部缓存键名截断后写进日志的副作用，不是外部输入。这个判断我还没有完全证实，所以只写在这里，供后来者参考。
日志时间差 0.3s待证实
线索 05
我在另一台机器上装了一个旧版本做对照，就是想看看索引文件的头部结构是不是变了。结论是变了：旧版头部是 32 字节，新版是 64 字节，多了一段校验区。这意味着把旧索引直接塞回新客户端，理论上可行但会被校验区判为无效。我第一次尝试就是这么失败的，客户端日志只写“格式不符”，没有任何细节。这个信息我后来在社区帖子第 47 楼找到了印证，发帖人叫“南岸旧书”，时间 2026 年 1 月 6 日。
头部 32 → 64 字节论坛第 47 楼
线索 06
那个帖子很长，前半段是各种“一键恢复”的广告，我没看。翻到后半段，有个回复说：先把缓存目录整体复制到另一块盘，在副本上做实验，原盘只读挂载。这句话我照做了，用了一块 256GB 的旧 U 盘，复制耗时 11 分钟。事实证明这是整个过程中最省时间的一步——后面三次失败的替换都发生在副本上，原盘一次没坏。
复制 11 分钟原盘只读
线索 07
凌晨四点十七分，我在便签上写了句“先别动”
那晚我差点把整个 `Caches` 目录删掉重来，手已经放到删除键上，停了三秒，最后没按。因为我突然想到，索引丢了可以重建，但缩略图缓存是没法重建的——那是几百个小时的扫描结果。后来我做了个决定：缩略图目录只读挂载，索引目录单独处理。这个决定让恢复时间多了两天，但保住了 29,860 张缩略图，这个数字我记得很清楚，因为它比清单上的 37,412 少，少的那些我到现在也没找齐。
2026-03-22 04:17保全 29,860 张
线索 08
还没答案的三个问题
第一，那 6 个缺失文件为什么恰好都在同一分卷的最后一段，是迁移脚本的边界 bug 还是磁盘扇区问题？第二，权限被改是系统更新导致的还是我自己某次 `chmod -R` 误操作？第三，客户端为什么不在日志里直接写“权限不足”，而要给一个模糊的错误码？这三个问题我到现在都没有答案，写在这里不是求解答，只是不想假装整件事已经闭环了。恢复本身算完成了，七成吧。
缺失 6 个文件完成度约 70%
