昨天下午三点二十分，我在整理一批 2024 年收藏的页面时，手指在触控板上滑了一下，选中了书签管理器里的第 47 个文件夹，然后按下了 Delete。Chrome 没有二次确认，那个文件夹连同里面 83 个页面直接消失。我先是打开回收站，空的；又打开书签管理器里的“撤销”，没有这个功能。那一刻我反而冷静下来，因为我意识到这个场景我其实经历过——就在今年一月，当时我用的是完全相同的路径，最后靠的是 49图正版库资料库恢复 里的索引说明才把页面找回来。区别在于，上次丢了 9 个，这次丢了 83 个。
丢东西这件事，数量不重要，重要的是你知道哪些丢了。
我把这次恢复过程拆成了三步，写下来更像是给自己留一份操作记录。第一步是确认浏览器的本地数据库位置。在 macOS 上，Chrome 的书签库位于 ~/Library/Application Support/Google/Chrome/Default/Bookmarks，它是一个 JSON 文件，2024 款 MacBook Air 上这个文件当时是 1.2 MB。第二步是检查是否有“Bookmarks.bak”备份文件，也就是上一次写入时的旧版本。那天运气不好，.bak 文件的时间戳是三天前的，丢掉的 83 个页面里有 21 个是三天内新增的，这部分没有找回来。第三步才是去翻网页快照和外部索引，把标题、URL、访问日期一条条对回来。
让我有点失望的是，整个过程里浏览器自己提供的能力几乎为零。它既没有版本历史，也没有删除缓冲，甚至连一个“你确定要删除这个文件夹吗”的对话框都没有。作为一个每天被调用的基础工具，这种设计显得有些漫不经心。我在 2022 年读过一篇关于浏览器数据持久化的论文，作者是某大学人机交互实验室的研究员，文中提到“浏览器书签的删除操作在多数实现中是不可逆的”，当时我没有太在意，现在回头看，这个结论比论文本身更值得记住。
但意外的收获也来自这里。为了找那 21 个新增页面，我第一次系统地使用了 Wayback Machine 的 CDX API，用 curl 请求了 14 次，拿到了 37 条快照记录。其中 26 条能打开，11 条返回 404。这个成功率比我预期的高。我还顺带发现，2019 年 6 月周明远写的那份 180 行脚本，核心逻辑和我手动敲的几行命令几乎是同一个思路——先按 URL 前缀检索，再按时间窗口筛选，最后把 HTML 存到本地。看别人的代码有时候就像读日记，能看出他当时遇到了什么问题。
整理到最后，我给自己定了一条规则：重要的页面不要只存在浏览器里。我把这次的 83 个页面里能恢复的 62 个，按主题分了七类，导出成了本地 HTML 文件，另外把其中 19 个反复访问的加进了笔记软件的“常看”列表。这个做法说不上优雅，但它让下一次的“恢复”变得不那么依赖运气。至于浏览器本身会不会在未来的版本里加入删除撤销，我不太乐观——过去五年里，它的更新日志里出现过很多功能，唯独没有这一项。
