single post · 实测记录

夜里十一点四十,我在 0149666.cm 的浏览器里把三个月的历史记录一键清空了

这不是一篇教程清单,而是一次恢复过程的完整复盘:Windows 上的 Chrome、macOS 上的 Edge、以及一台还在跑 Firefox ESR 的老机器,各自的路径、时点与代价,我都记了下来。

作者:江晚 发布于 2026-06-01 栏目:浏览器与本地数据 阅读约 9 分钟

本期文章

共 10 篇 · 按发布时间倒序
夜间使用笔记本电脑的场景 详情 · 主文

0149666.cm 浏览器打开历史记录恢复:一次误清空之后的四小时

事情发生在上个月 28 号的晚上。我在旧笔记本上给一个跑了两年的项目做最后一次归档,屏幕右下角的时间跳到 23:41,我伸手去点「清除浏览数据」,原本只想勾掉缓存,结果手滑把「浏览记录」和「Cookie」一起选上了,点下确认之后的那一秒,我甚至听见了自己心里「咯噔」一声。

接下来四个小时我做的事情,大致可以分成三段:先在 Windows 的 Chrome 里找 History 文件的残留,再去 macOS 上的 Edge 翻快照目录,最后把一台还装着 Firefox ESR 的旧机器当作对照样本,看它的 places.sqlite 是不是更好说话。结论是——浏览器历史记录的恢复,本质上不是「找回丢失的东西」,而是「在覆盖之前抢时间」,这句话我后面会反复说。

具体到 手机qq浏览器默认打开首页 这一类移动端场景,路径其实还要更麻烦一点,因为手机的写入频率比桌面高得多,留给你的窗口更窄。我在第三段里会专门用一段讲这个差异。

「历史记录不是文件,是索引;你清掉的不是内容,是访问它的那张地图。」——这是我自己在凌晨两点写在便签上的一句话。

先说 Chrome。Windows 下它的数据库在 %LOCALAPPDATA%\Google\Chrome\User Data\Default\History,这是一个 SQLite 文件。你点「清除」的瞬间,Chrome 并不会真的把整张表抹掉,它会先做一次 VACUUM 式的重写,把空闲页释放掉。所以严格来说,第一时间应该做的是停止一切写入:关掉浏览器、关掉同步、不要再打开任何网页。我当时的错误是清完之后又开了五个标签页去查资料,等于亲手把旧页覆盖了一遍。

第二步是找备份。Chrome 自身不保留 History 的历史版本,但 Windows 的「文件历史记录」和 macOS 的 Time Machine 会。我在那台机器上恰好开着「文件历史记录」,于是从 23:00 那个整点快照里捞回了一份两小时前的 History 文件,覆盖回去之后,恢复了大约 83% 的条目——丢失的主要是当晚那两小时里的访问,以及所有带表单输入的搜索词。

Edge 的情况不太一样。macOS 上它的数据在 ~/Library/Application Support/Microsoft Edge/Default/,其中 History 同样是 SQLite,但 Edge 会额外维护一个 History-journal 文件,如果这个 journal 还在,理论上可以用 SQLite 的 .recover 命令抢救出一部分。我试了,捞回了 11 条,不多,但其中恰好有一条是我找了很久的文档地址。顺带提一句,如果你在找 imtoken钱包app下载安卓版v2.9.7 这类具体版本页,提前把地址存进书签比事后恢复靠谱得多。

Firefox 是这三者里最「讲道理」的。它的 places.sqlite 默认会保留一份 places.sqlite.corrupt 的旁路文件,而且在「工具—设置—隐私」里可以开启自动备份,备份循环保留最近 15 份。那台旧机器上正好有一份三天前的备份,我用它做了对照,验证了一个判断:Firefox 的恢复成功率高的原因,不在于它的表结构更简单,而在于它把「快照」做成了默认行为,而不是让你去赌系统还原点。

写到这里,我得说一句可能不太受欢迎的话:市面上绝大多数宣称「一键恢复」的工具,对已经执行过清除操作的浏览器历史记录,实际效果接近于零。它们能做的是扫描磁盘上尚未被覆盖的 SQLite 空闲页,这需要满足两个条件——清除后你几乎没有再使用过这台机器,以及磁盘没有被 TRIM 过。对于 SSD 用户,第二条基本不成立。我看到太多人在论坛里花了几百块买软件,最后只捞回几条三天前的无关记录,这不是他们的错,是宣传的错。

关于 澳门凤凰网正版图库 这类需要频繁核对来源的站点,我的建议是别把它交给浏览器历史:用笔记软件建一个「来源台账」,每次访问完就把链接和摘要贴进去。历史记录是给「随手回看」用的,不是给「证据留存」用的,把这两件事混在一起,迟早会出今晚这样的事故。

最后一个细节,也是我当晚最大的收获:Chrome 在 Windows 上其实有一个隐藏的 History Provider Cache,位于 Default 目录下,是个 JSON,里面存着最近若干条访问的模糊摘要。我用文本编辑器打开它,逐行读,居然认出了两条我下午访问过的页面标题。它不完整,也不可靠,但在别的路都堵死的时候,它证明了一件事——数据从来不是「被删除」,而是「被降级」。浏览器打开网站62849入口 那种带跳转的页面尤其如此,你看到的消失,往往只是路径被重写了。

四个小时之后,天快亮了,我把能恢复的恢复完,把恢复不了的列成一张清单,存在桌面上,命名为「下次别再犯」。这份清单现在还在,第一条写着:清理前,先复制 User Data 目录。第二条:不要在清完之后立刻用同一台机器查资料。第三条,也是最重要的一条——把重要的地址放进书签,而不是交给历史记录去记。

文 / 江晚 2026-06-01
工具

用 sqlite3 的 .recover 命令抢救 History 文件时的三个坑

我在 5 月 19 日晚上八点半,把一份 6.4 MB 的 Chrome History 副本拖进命令行,试图用 .recover 重建表结构。第一个坑是 WAL 模式,文件头里还挂着 -wal 和 -shm,必须先合并;第二个坑是时间戳,Chrome 用的是 1601 年起的微秒数,直接读会得到一串看不懂的数字;第三个坑最要命,恢复出来的表没有索引,你需要手动重建 urls 和 visits 的关联,否则访问次数全是 1。

江晚2026-05-21
移动端

安卓 Chrome 的历史记录库藏在 /data/data 下,普通用户摸不到

5 月 12 日我试着在一台没 root 的 Pixel 上找历史记录文件,结论很干脆:找不到。应用沙箱把 /data/data/com.android.chrome 挡在外面,adb backup 从 Android 12 起也不再对这类应用生效。唯一可行的路径是 Chrome 自身的同步——如果你的账号开着「同步历史记录」,网页版 myactivity.google.com 里有完整条目;如果没开,那就真的没有了。这件事让我对「本地优先」这四个字有了新的理解。

江晚2026-05-14
观点

《数据恢复实战》这本书的第二章,我认为被高估了

这本书在圈内口碑很好,作者是位做了十几年取证的老工程师,案例扎实。但第二章「浏览器痕迹恢复」那一节,我读完之后有点失望。它花了 14 页讲如何用十六进制编辑器逐字节扫描,却只用一句话带过了「SSD TRIM 会让这条路彻底失效」。对于 2026 年的读者,这个权重分配是反的。我把这段批注写在了书页边上,用的是蓝色圆珠笔,写完之后自己看了半天。

江晚2026-05-09
系统

Windows「文件历史记录」默认是关的,这是很多人恢复失败的根本原因

4 月 22 日下午,我在朋友的一台联想小新上帮他找三个月的浏览记录,打开控制面板一看,文件历史记录从买来那天起就没开过。备份驱动器那一栏是空的。我当场建议他外接一块 1TB 的移动硬盘,设置每天凌晨两点整点快照。他问我值不值,我说你上周丢的那份合同就值。这件事之后,我把自己家里三台机器全部检查了一遍,两台没开。

江晚2026-04-25
对照实验

Firefox 的 places.sqlite 自动备份,我连续观察了 21 天

从 3 月 30 日到 4 月 19 日,我每天记录那台旧机器上 bookmarkbackups 目录里的文件生成情况。结论:它每天生成一份,保留 15 份,滚动覆盖,命名格式是 bookmarks-2026-04-19_1234_随机串.jsonlz4。这个机制本来是给书签用的,但因为它保存了部分访问元数据,在极端情况下能当作间接证据。21 天里它一次没漏,稳定性比我想象的好。

江晚2026-04-20
方法

恢复的第一步永远是「停止写入」,但九成人做不到

4 月 3 日我在一个技术群里做了个小调查,问了 27 个人:发现历史记录被清空之后,你做的第一件事是什么。19 个人回答「重新打开浏览器查怎么恢复」。这个答案看起来合理,实际上是在给自己制造更大的麻烦,因为每一次打开都会往同一个 SQLite 文件里写元数据。真正该做的是断网、关进程、把整个 User Data 目录复制到另一块盘再操作。

江晚2026-04-05
书摘

《数字取证手册》第三版里有个被忽略的注脚

3 月 17 日我在图书馆四楼翻这本书的第 3 版,第 214 页底部有个小号字的注脚,大意是:在 macOS 上,Safari 的 History.db 会随 Time Machine 的本地快照一并备份,即使你没有接外置硬盘,系统每 24 小时也会留一份。我照着注脚试了,用 tmutil listlocalsnapshots 列出了 5 份本地快照,最早那份是 3 月 14 日凌晨的,里面确实有可用的 History.db。

江晚2026-03-19
习惯

我把「来源台账」从笔记软件搬进了本地纯文本

2 月 26 日,我停用了用了三年的某笔记软件,把所有的来源记录导出成 Markdown,按年月分文件夹,每一条包含链接、标题、访问时间、一句摘录。这个改变很笨,但很稳。三个月下来这个目录里有 1,247 个文件,占 38 MB。它不会因为我误点一次清理就消失,因为它躺在第三方同步盘和一块离线硬盘里,各一份。

江晚2026-03-01
杂记

第一次写恢复笔记,是在 2024 年冬天的一个下午

2024 年 12 月 9 日,我在一家咖啡馆里,用一张 A5 的方格纸画了 Chrome User Data 目录的结构图,画到 Default 下面的 History 时,笔尖顿了一下,因为我不确定 -wal 文件到底算不算它的一部分。那天下午我查了快两个小时,最后在 Chromium 的源码注释里找到了答案。那张纸我留着,夹在笔记本第 40 页,纸边已经有点卷了。

江晚2026-02-11
江晚的工作桌面一角

关于我

江晚 · 独立研究者 / 这个站点的唯一作者

我叫江晚,从 2019 年开始给几家技术媒体写浏览器与本地数据相关的稿子,2024 年起把大部分精力放在这个站点上,主要做一件事:把「数据到底存在哪里」讲清楚。

我不用「一键恢复」这类词,因为我做了七年多的实测,见过太多工具把用户的期待拉得很高,最后只捞回两条无关记录。我更愿意写清楚路径、时间窗口和失败的边界,哪怕读者看完之后说「原来救不回来」,那也是一次诚实的交付。

这个站点没有团队,没有投稿入口,也没有广告位。每篇文章都是我亲手跑一遍、把终端输出和文件时间戳抄下来之后再写的,所以更新慢,一个月大概三四篇。

写今晚这篇的时候,我的心情有点复杂:失望是因为我确实没能把那两小时的记录找回来;收获是因为那个 History Provider Cache 文件,是我翻了两年的目录结构之后才第一次注意到的。

今天看到的一句话
「删除不是把字擦掉,是把书架上那本书的编号换给了另一本书。」
—— 出自 《数字取证手册》第三版,第 209 页,作者在讨论文件系统空闲页复用机制时写下的一句话。我今晚翻了三次,越读越觉得它在讲我。