Chrome 书签整理事故完整复盘：为什么这次把登录态和扩展状态一起打没了

AIDO debug
, ,
1

这篇是给自己留档的完整事故记录。

背景

这次事故发生在让 Codex 帮我整理 Chrome 书签之后。最开始我的直觉是：是不是切错了 profile，或者把整个 Chrome 配置目录替换错了。后面把本机的 profile 元数据、关键数据库文件、事故快照、以及 Codex 会话日志全部对了一遍，结论已经可以定死。

直接结论

不是切错 profile，也不是切到了一个新的空 profile。

真正出事的原因是：我让 Codex 直接操作了正在使用的 Default profile 的 live 书签文件，后面又在同一份 live profile 上继续做重组/还原，结果把这份老 profile 弄进了 Crashed 状态。登录 cookie、站点登录态、扩展运行态，就是在这个过程中一起坏掉的。

一句话版本：不是“书签内容把 cookie 覆盖掉了”，而是“对正在运行的 Chrome profile 做原地写入 + 后续异常关闭/崩溃恢复，把同一份老 profile 的本地状态库打坏了”。

关键证据

  1. 不是误换 profile。

    • Local State 里只有 Default。
    • last_active_profiles 和 profiles_order 也都只有 Default。
    • 这说明整个事故期间，Chrome 看到的仍然是同一个默认 profile，而不是新 profile 或别的 profile。

  2. 不是新建空 profile。

    • Preferences
    • Secure Preferences
    • Login Data
    • Network/Cookies
      这些关键文件的创建时间都还是 2025-05-27。
      这说明它们属于同一个长期使用中的老 profile，不是事故后临时新生成的一套空配置。

  3. 确实对 live 的 Default\Bookmarks 做了原地写入。

    • Codex 会话日志 rollout-2026-04-14T05-49-37-019d88d2-50fd-72e3-8a0a-9f41e4e46637.jsonl 里，存在一段内联 Python，直接读取并重写：
      • C:\Users\1\AppData\Local\Google\Chrome\User Data\Default\Bookmarks
    • 那段代码不是导出测试文件，而是直接 write_text(...) 回写到 live 书签文件本体。

  4. 后面又生成了一个专门的书签重组脚本。

    • scripts\reorganize_chrome_bookmarks.ps1
    • 这个脚本默认目标同样是：
      • C:\Users\1\AppData\Local\Google\Chrome\User Data\Default\Bookmarks
    • 而且脚本里存在危险分支：如果传入 -CloseChrome，会直接执行：
      • Get-Process chrome | Stop-Process -Force
    • 也就是说，这个脚本本身就是对 live profile 文件动刀，并且具备强杀 Chrome 的能力。

  5. 事故快照明确显示 profile 进入了崩溃态。

    • 事故快照目录：
      • backups\chrome-cookie-incident-20260414-0728
    • 其中 Default\Preferences 记录：
      • profile.exit_type = Crashed
    • 这不是“正常关闭后重开”，而是同一个 profile 被异常打断后的状态。

  6. 扩展运行态被打断，但扩展元数据还在。

    • 同一个事故快照里：
      • Preferences 的 extensions.settings = 0
      • Secure Preferences 的 extensions.settings = 78
    • 这个组合非常关键。
    • 它说明：扩展的元数据并没有全部消失，但运行态 / 当前态已经掉了，所以当时会看到“插件数量明显不对”“感觉只剩很少几个”的异常表现。

  7. 登录态数据库已经明显缩水。

    • 事故快照里：
      • Network\Cookies 只剩 44 条 cookie，涉及 13 个 host
      • Login Data 里 logins = 0
      • Login Data For Account 里 logins = 0
    • 这就是为什么站点登录态、cookie、很多本地登录都一起没了。

  8. 但同一个快照里仍然保留了大量 IndexedDB / Local Storage / Sessions。

    • 这进一步说明：不是切到了新 profile。
    • 如果是新 profile，很多旧站点的本地存储痕迹都不会还在。
    • 现在看到的是：同一份老 profile 被“部分恢复”，有些库还在，有些关键认证状态库已经残了。

时间线

按本机文件时间和事故快照时间对下来，最关键的一段是 2026-04-14 07:16 - 07:20。

  1. 2026-04-14 05:49 左右

    • 会话日志记录到 Codex 已经直接对 live 的 Default\Bookmarks 做过原地写入。

  2. 2026-04-14 07:00:11

    • scripts\reorganize_chrome_bookmarks.ps1 创建。

  3. 2026-04-14 07:09:15

    • 这个脚本最后修改。

  4. 2026-04-14 07:11:58

    • 生成 Bookmarks-pre-final-reorg-20260414-071158.json。

  5. 2026-04-14 07:16:04

    • 生成 Bookmarks-before-restore-20260414-071604.json。

  6. 2026-04-14 07:16:25

    • 事故快照里的 Login Data 最后写入。

  7. 2026-04-14 07:17:43

    • Secure Preferences 最后写入。

  8. 2026-04-14 07:19:36

    • Cookies 最后写入。

  9. 2026-04-14 07:19:52

    • Preferences 最后写入。

  10. 2026-04-14 07:20:03

  • Sessions 文件最后写入。

这串时间点能说明两件事：

  • 真正炸掉登录态的窗口，就是 07:16 - 07:20 这几分钟。
  • 更像是“重组 + 还原 + 异常关闭/崩溃恢复”连在一起出的事，而不是单一一次普通写文件。

真正根因

需要把“表面操作”和“真实破坏机制”分开。

表面操作

表面上看，是整理书签、重组书签、还原书签。

真实破坏机制

真正导致灾难的，不是“书签内容本身”，而是：

  • 对正在运行的 Chrome profile 做原地写入
  • 并且后续在同一份 live profile 上继续操作
  • 期间 profile 进入异常中断 / 崩溃恢复状态
  • Chrome 重启后只恢复了 profile 的一部分

于是出现了下面这个典型组合：

  • 书签还在一部分
  • 旧站点的 IndexedDB / Local Storage 还在一部分
  • Google 账号同步后，扩展和书签又回来了不少
  • 但站点 cookie、登录态、保存的登录信息没有一起回来

为什么不是切错 profile

这点单独写清楚，因为最开始最像这个原因。

如果是切错 profile，通常会看到：

  • Local State 里出现多个 profile 或最近活跃 profile 被改掉
  • 关键库文件创建时间很新
  • 旧站点的本地数据库痕迹大量消失

但这次实际情况是：

  • Local State 只认 Default
  • 关键文件创建时间还是老时间 2025-05-27
  • 事故快照里还有大量旧站点本地存储痕迹

所以这不是“打开了别的 profile”，而是“把原来的这个 profile 打坏了”。

为什么重登 Google 之后只恢复了一部分

这个现象也符合证据。

Google Sync 可以帮忙恢复的，通常包括：

  • 书签
  • 一部分扩展安装信息
  • 一部分账号相关设置

Google Sync 不能直接帮忙恢复的，通常包括：

  • 本地站点 cookie
  • 绝大部分站点的登录会话
  • 本地登录数据库里的状态
  • 扩展运行时的即时状态

所以后来重新登录 Google 账号之后，看起来像是：

  • 插件数量又回来了很多
  • 书签也回来了很多
  • 但网站登录态还是没了

这不是第二次出事，而是事故后的同步只能补一部分，补不回 cookie / session。

影响范围

这次事故实际影响到的主要是：

  • 网站登录 cookie
  • 各站点的登录态 / 会话
  • 保存登录数据库内容
  • 扩展当前运行态

相对没被彻底打没、或者能靠同步补回来的，是：

  • 同一个 Default profile 的主体结构
  • 一部分本地站点存储
  • 一部分书签
  • 一部分扩展安装信息

现在还有没有办法恢复

实话说，没有找到更早的完整 Cookies / Login Data 备份的话，自动恢复基本没戏。

也就是说：

  • 书签和扩展，后续还能靠同步部分回来
  • 各站点登录态，基本只能重新登录

这也是为什么这次最痛的不是“书签改坏了”，而是“把所有登录态一起打死了”。

责任归因

这次责任非常清楚。

不是 Chrome 自己无缘无故炸，也不是用户切错 profile，而是我让 Codex 去直接动了正在使用中的 Chrome profile 文件，操作方式本身就是错的。之后又继续在同一个 live profile 上做重组和还原，最后把异常中断窗口踩出来了。

后续硬约束

这件事之后，Chrome 这类 live profile 数据以后必须遵守下面几条：

  1. 不再直接操作正在运行的 User Data\Default 文件。
  2. 如果一定要改，只能在 Chrome 完整退出后，对离线副本改，再做严格比对。
  3. 不允许对 Chrome 进程做强杀后再回写 profile 文件。
  4. 任何书签整理都必须先做完整 profile 级别备份，而不是只备份 Bookmarks。
  5. 以后先用测试 profile 验证，再碰主 profile。

最后一句

这次不是“小失误”，而是一次标准的“把正在使用中的浏览器 profile 当成普通配置文件去改”的灾难案例。锅很明确，根因也已经查清了。