上周二晚上十点四十，我盯着那个空白列表看了整整二十分钟

从「看不见」到「找得回」之间，隔着的其实是对丢失类型的判断

我先把结论摆在这里：资料丢失不是一个问题，而是至少三类问题的统称——显示层失效、索引层断裂、存储层覆盖。三者的应对路径完全不同，搞错类型，越努力越糟。上周二那晚我犯的第一个错，就是默认它是第一类。

显示层失效最好处理。清一次浏览器缓存、换一个内核、关掉某个拦截扩展，页面往往就回来了。判断方法是：换设备或换网络后，同一页面是否正常。如果手机流量下能看到，那问题基本在本地。这条路径我建议放在最前面试，它的成本最低，也最不伤数据。

索引层断裂要麻烦一些。列表页空白、搜索能出标题但点不进去，这类现象我在 49图库恢复指南 里读到过更细的描述，它把这种情况归为「关联表失联」。我的经验是，此时不要去反复刷新或批量重试，那只会让服务端日志更乱，反而干扰后续定位。

存储层覆盖是最难的一种，也是我这次真正担心的。它的特征是：条目消失得干净，历史接口也不留痕。8 月 29 日晚上，陈默在电话里跟我说了一句让我印象很深的话——「你看到的空白，不一定是空的，可能只是没人告诉它该显示什么。」这句话后来成了我整个排查的指导原则。

具体到我自己的操作，我做了四件事。第一，把当前浏览器配置目录整个复制了一份到外置盘，1.2GB，不做任何修改；第二，导出历史记录与书签为明文；第三，用 Everything 按修改时间筛出上周二 22:00 至 23:30 之间变动的所有文件，共 68 个；第四，逐个看文件头，排除被截断的。

需要说明的是，不同内核的浏览器，缓存与站点数据的存放位置不一样。我在 qq浏览器海外版网站进入 这个页面的说明里看到过一份路径对照，虽然讲的是另一个产品，但目录结构逻辑相通，省了我不少翻文档的时间。

还有一个入口我差点漏掉。如果你平时会同步书签，那么同步服务端通常会保留最近若干次的书签快照。我翻自己的同步记录，找到了 8 月 24 日的一份，里面有 12 条当时已收藏但后来在本地消失的资料地址。这条路径的前提是：你确实开过同步，而且没有手动清空过云端数据。

关于工具的选择，有人问我为什么不直接用数据恢复软件扫盘。我的看法是：可以扫，但要先做镜像。直接在原盘上跑恢复工具，写入操作有可能覆盖掉本来还能救的区块。这句话听起来像老生常谈，但我在 9 月 1 日那天差点自己犯这个错，是张北辰拦住了我。

回到那些没答案的问题。第一，22:41 之后写入全部失败，但读取部分成功，这种「半瘫痪」状态的成因我还没想清楚；第二，19 分钟的日志空白究竟是采样间隔问题还是进程挂起，我没有证据；第三，如果索引表是断裂而非删除，为什么部分条目的正文连历史接口都查不到。这三个问题我暂时搁置，等有新的日志再看。

顺手说一句可能不太受欢迎的话：这类资料库产品在做备份策略时，普遍把「可访问」当成了「可恢复」，这两件事不是一回事。一个按钮能点开，不代表数据有第二份。我见过太多案例，恢复能力是在事故之后才被讨论的，这个顺序本身就是问题。这也是我写这个站的原因之一。

最后给一个我自己的操作顺序，仅供参考：先换环境确认是不是显示层；再导出历史与书签；再整目录镜像；最后才动恢复工具。中间任何一步如果发现异常，停下来记日志，比继续往前冲有用。我在 60949.cm浏览器 那一页也提过类似的分步思路，两处可以对照着看。