凌晨两点半，我在旧笔记本的 Chrome History 文件里翻到 2019 年 3 月 17 日的一整页链接——那一刻我才明白，浏览记录不是文件夹，而是时间本身。

把 Chrome 的 History 文件拷到 D 盘后，我用 DB Browser 看到了 2019 年 3 月 17 日的 47 条访问记录

文件位置在 User Data\Default\History，是 SQLite 库，不是纯文本。拷副本、别原地打开，是第一条铁律。表 urls 与 visits 通过 id 关联，时间戳是 1601 纪元微秒。

林姐的旧 ThinkPad 换了硬盘，Cache 目录里还剩 213 个 f_ 开头的二进制文件

她只记得「一个蓝底白字的页面」，我用 ChromeCacheView 按时间筛，命中 6 条，逐条还原出标题。动作很笨：用十六进制编辑器把 URL 段截出来，存成 txt，再人眼比对。

浏览记录恢复其实是「时间线拼接」：三份来源互相印证，缺口才算补上

来源一，History 库；来源二，Cache 与 Sessions 目录；来源三，系统层面的 DNS 缓存与网络日志。三者时间精度不同，History 到秒，DNS 常只到分钟。

我的做法是先画一条空白时间轴，把能确定的事件钉上去，剩下的用「相邻访问」推。缺口不必填满，标出缺口本身就是结论。

给一家小公司做设备交接时，我导出了 1,842 条记录，按日期分 11 个 CSV

导出列固定为：时间、标题、完整 URL、来源表、置信度。置信度分三级，A 是库内直读，B 是缓存还原，C 是推演。客户要的是可复核，不是看起来完整。

安卓手机上「历史记录空白」十次里有七次不是丢了，是账号同步切换了

先看浏览器账号栏是不是登成了另一个邮箱。登录态一变，历史列表立刻「清空」，其实本地库还在。切换回去，记录原样回来。这个坑我 2024 年踩过两次。

用 PowerShell 把 History 库的 visits 表按小时聚合成柱状图

脚本 41 行，不依赖第三方包。输出到控制台是第一版，后来改成写 CSV 再丢进表格画图。深夜时段的访问密度一眼就能看出来，那是找「当时在干什么」的捷径。

我不太相信「浏览器自带的历史恢复」按钮，多数情况下它只是把同步拉回来的列表重新挂上

说句可能被同行反驳的话：把同步数据说成「恢复」，是在偷换概念。真正的恢复要看本地文件是否还在、是否没被覆盖。分清这两件事，才不会在关键时刻判断失误。

周老师在机房让学生打开 chrome://history 时，有 6 台机器跳到了空白页

原因是策略组禁用了历史页面。改 HistoryPage 策略，或换用 chrome://history/syncedTabs 看另一层。机房场景下，策略往往比文件损坏更常见。

Firefox 的 places.sqlite 比 Chrome 更友好：一张 moz_historyvisits 表就说清了 2,304 次访问

好处是字段语义清晰，坏处是写锁更严。拷副本前先退出浏览器，否则拷出来的是半截库。我在 2023 年因为没退出，丢掉过一整晚的成果。

误点「清除浏览数据」之后的 30 分钟，是最值钱的 30 分钟

先别再用这台机器上网，把库文件、缓存目录、Sessions 整包拷到移动硬盘。用数据恢复工具扫未分配空间，命中率随时间衰减。动作要快，别先截图发朋友圈。

恢复别人的浏览记录之前，先问一句有没有授权：这不是技术问题

我拒接过两单，理由一样——设备不是委托人的。技术能做的事和应该做的事之间，得有一条线。写在这里，也写给自己。

把 chrome://version 里的「个人资料路径」抄下来，比在菜单里找历史快得多

路径拿到了，History、Bookmarks、Web Data 全在同一层。做恢复时我把这一层整个打包，命名用日期加机器名，比如 20260621_ThinkPad。