Single Post · 记录

关于恢复观看历史记录69次的一些记录

2025 年 12 月 1 日晚上十一点四十分,我把那台 2021 年的旧笔记本从柜子里搬出来,屏幕亮起来的那一刻,我知道这是第 69 次了。这件事我本来不想写的,但今晚必须写。

作者 江晚 发布于 2025-12-02 字数约 2600 标签 数据恢复 / 浏览器 / 存档

第 69 次,从一个快要没电的路由器说起

昨天下午三点二十分,我在书房里把路由器断电重启了第二次,指示灯从红跳到绿的那七秒钟里,我盯着屏幕上一片空白的“观看历史”页面,突然意识到这已经是第 69 次尝试恢复它。桌上摊着三张便签:一张写着 Chromium 缓存目录的路径,一张记着某个开源项目在 GitHub 上的 issue 编号,还有一张是中午十二点四十吃剩的半块面包旁压着的、用蓝笔写的“不要格式化”。我妻子在客厅喊我问要不要订晚饭,我回了一句“等一下”,然后继续把开发者工具切到 Application 面板,点开 IndexedDB,里面空空如也,只有一条名为 records 的对象仓库,记录数为零。

这件事得从 2024 年 8 月说起。那台旧笔记本上存着我从 2019 年到 2024 年累积的观看历史,横跨三个不同的流媒体平台,粗略估算有两万多条,其中有整整七个月的记录我用来做一份关于“纪录片观看时长与睡眠质量”的自我观察笔记,那七个月的数据和观看历史是绑定的,历史没了,笔记就成了一堆没有上下文的孤立时间戳。我试过用 qq浏览器进入网站 的本地缓存路径去捞,也试过把整个 User Data 目录复制到另一台机器上做冷备份再解析,结果都是徒劳——2023 年之后的浏览器版本把历史记录加密和分片做得非常彻底,靠手动翻文件夹基本等于在垃圾场里找一张写着密码的收据。

到底有没有“恢复”这回事

我必须说一句可能得罪人的话:大多数打着“一键恢复观看历史”旗号的工具,本质上做的是重建,而不是恢复。它们读的是你账户在服务端留下的行为日志、cookie 里的会话标识、以及本地残留的 SQLite 页面碎片,然后拼出一个“大概像那么回事”的列表。这中间的差别是致命的,因为一份被重建出来的历史,时间戳会漂移、条目会重复、序列会错乱,它看起来很像你失去的东西,但你一旦把它当作原始证据去用,就等于把一份赝品当成了档案。我在 2025 年 5 月做过一次对照实验,用两种市面常见的恢复方案处理同一份快照,结果 A 方案找回了 1142 条,B 方案找回了 1307 条,两者重合的部分只有 803 条,而且对同一条记录的时间标注相差最多达到了 19 个小时。

所以从第 40 次尝试之后,我改变了策略:不再追求“恢复全部”,而是建立一个可验证的恢复链。具体做法是先用 49图库资料免费打开网站入口技术支持 里提到的冷读取思路,把磁盘镜像挂成只读,再用脚本按 SQLite 页结构与 WAL 日志逐页扫描,凡是能定位到完整记录的,才打上“可信”标签;定位不到的,一律标记为“待核”。这个流程很笨,一次完整的扫描要跑将近两个小时,但它是目前唯一能让我对自己的数据保持诚实的方式。

第 55 次尝试时,我在日志里写了一句话:“恢复的意义不在于找回多少条,而在于你能说清楚每一条为什么在。” —— 江晚的工作日志,2025 年 9 月 17 日 凌晨 1:04

那些具体的失败

第 58 次,我把希望寄托在 7744.cc浏览器 提供的导出接口上,接口确实返回了 4.7MB 的 JSON,我用 Python 解析之后发现里面只有 621 条记录带完整的时长字段,其余全是空的播放位置。第 61 次,我托朋友从一台同型号的机器上取了一块没写过的 SSD 做对照,确认问题不在介质老化,而在浏览器自身的写入策略——它对每一条历史记录做了分片校验,任何一片损坏整条就作废,这就是为什么我的两万多条里最终只有不到十分之一能被完整重建。第 64 次,我花了整整三个小时研究 49tk图库下载官网 这类站点在浏览器里的资源加载轨迹,试图从缓存索引反推观看顺序,结论是索引本身也被滚动覆盖了,最早的一批条目在 2024 年 11 月就被挤掉了。

第 67 次是最接近成功的一次。我从一份 2024 年 12 月的 Time Machine 备份里找到了一份完整的 LevelDB 目录,用只读方式挂载,跑了一个 40 分钟的重建脚本,最终得到了 2138 条带时间戳的记录,其中有 1403 条能和服务端的月度观看报告对上。那一刻我甚至有点想哭,但很快发现这 2138 条里没有 2023 年上半年那一段——那七个月的笔记依然找不到它的另一半。第 68 次,我尝试用 数字49图库图片 相关的图像元数据去交叉验证观看时间,失败了,因为那批截图本身的 EXIF 在导出时就被剥掉了。

为什么我还是不满意

坦白讲,我对目前市面上所有“历史记录恢复”的叙事都不满意,这是我这篇文章里最想说的个人观点。它们把数据恢复包装成一个按钮,却从不告诉你恢复的边界在哪、哪些是原生的、哪些是猜出来的。我做过统计,在我测试过的 11 种方案里,有 7 种在结果页面上不做任何可信度标注,用户拿到的是一份混着真实与推断的列表,却被暗示成“全部找回”。这不是技术问题,是诚实问题。我甚至认为,对个人数据而言,一份明确标注“仅恢复 12%、其余不可验证”的报告,比一份看起来完整的列表更有价值,因为它尊重了档案的本质——档案的前提是可追溯,而不是看起来齐全。

现在是 12 月 1 日的深夜,第 69 次尝试刚刚结束,结果和前面 68 次一样,那七个月仍然空着。我把日志合上,把三张便签收进抽屉,然后把笔记本关了机。我写下这些,不是为了宣布一个解决方案,而是想留下一份诚实的记录:一个人、一台旧电脑、69 次尝试,以及那些最终没能回来的 2138 条之外的空白。

相关的记录与旁证

以下 9 条是我在这 69 次尝试中留下来的线索,按时间倒序。

日志

9 月 17 日凌晨 1:04:第 55 次失败后的那句自问

“恢复的意义不在于找回多少条,而在于你能说清楚每一条为什么在。”

2025-09-17 · 工作日志
实验

5 月 22 日:两种方案对照,重合仅 803 条

A 方案 1142 条,B 方案 1307 条,时间标注最大偏差 19 小时。对照表共 4 页。

2025-05-22 · 江晚
备份

第 67 次:从 2024 年 12 月 Time Machine 里救回 2138 条

1403 条可与服务端月度报告对上,但 2023 年上半年依然缺失。

2025-11-19 · 江晚
结构

只读挂载 + WAL 逐页扫描:一次跑 1 小时 52 分

凡是能定位完整记录的才打“可信”,其余标“待核”。笨,但诚实。

2025-10-08 · 方法笔记
失败

第 58 次:导出 4.7MB JSON,只有 621 条有时长

播放位置字段大面积为空,接口返回完整,但内容不完整。

2025-10-30 · 江晚
对照

第 61 次:同型号机器 + 未写过的 SSD 对照组

确认问题不在介质,而在浏览器分片校验策略:一片坏,整条废。

2025-11-05 · 江晚
索引

第 64 次:缓存索引被滚动覆盖,最早条目 2024 年 11 月丢失

花了三个小时反推观看顺序,结论是索引本身已无法复原。

2025-11-12 · 江晚
元数据

第 68 次:截图 EXIF 已被剥离,交叉验证失败

原本想用图像时间戳补全观看时间,导出时元数据就没了。

2025-11-28 · 江晚

关于我

我叫江晚,做数字档案与个人数据保存相关的研究,白天在一家做图书馆数字化的机构上班,晚上回来写这个站。我从 2019 年开始系统地记录自己的观看历史,本来只是想弄明白自己一年到底看了多少部纪录片,后来这件事变成了一项长期的、近乎偏执的存档练习。

这个站是我存放这些记录的地方,里面没有教程,也没有“三步搞定”的承诺,只有每次尝试的原始日志、失败原因和可复现的步骤。我写它,是因为我在网上找不到一份诚实地承认“恢复有边界”的中文材料,而我又恰好踩过了这 69 次坑,那就由我来留下这些痕迹。如果它能让你在动手格式化之前多犹豫三分钟,这个站就没有白建。

研究领域:数字档案 / 个人数据保存 记录起点:2019 年
档案的价值不在于它保存了多少,而在于它能否被解释、被追溯、被信任。
—— 引自 特里·库克《档案与社会》,转引自 2025 年 11 月 30 日我在市图书馆借阅的那本 2018 年第二版,第 87 页