一次把 Chrome 登录态和扩展搞乱的复盘：不要在真实 Profile 上做远程调试

通用
,
1

这是一篇给自己看的警醒帖。调试chrome插件时，把 Chrome 的真实日用 Profile 拿去做扩展同步，结果把登录态和扩展状态搞乱了。

先说结论：这不是“Chrome 自己抽风”，而是一次错误的自动化操作。

本地 session 里确认到的事实

  • 先执行了强制结束 Chrome 的命令，相当于直接把正在使用的浏览器进程砍掉。
  • 随后重新启动真实 Chrome，并直接指向真实用户目录的默认 Profile。
  • 启动参数里包含远程调试端口，以及 --disable-sync。
  • 目标页面是 All API Hub 的扩展设置页。
  • 本地 helper 代码里本来有“Chrome 正在运行就退出”的保护，但实际操作前先把 Chrome 强杀了，等于把这层保护绕过去了。

为什么会出问题

Chrome 的登录态、扩展注册、同步状态、部分偏好设置，都和真实用户目录强绑定。
当我对真实 Profile 同时做了这几件事：

  • 强杀运行中的 Chrome
  • 带远程调试去接管真实 Profile
  • 在真实 Profile 上加 --disable-sync

结果就是把“我平时日用的浏览器状态”和“自动化临时操作”混在了一起。
这类操作不一定会把底层数据完全清空，但很容易让表层状态出现错乱，比如：

  • Google 账号看起来像退出登录
  • 扩展暂时消失或重新注册
  • 扩展设置/同步状态出现回退
  • 部分站点登录态、窗口/会话恢复表现异常

这次的恢复情况

这次后续通过重新登录 Chrome，并等待扩展与设置重新同步，主体功能基本恢复。
这也说明很多底层数据并不是“全没了”，更像是 Chrome 账号层、同步层、扩展注册层被我自己搅乱了。
但“能恢复”不代表做法没问题，因为中间造成的混乱和不确定性是真实存在的。

查历史 session 的结果

我去翻了本地归档。
结论是：

  • 2026-04-25 这次，有完整且明确的证据链。
  • 更早是否发生过“同样的强杀 Chrome + 接管真实 Default Profile”的事故，我目前没在本地归档里找到同等确定性的证据，只能说以前可能有相似感觉，但这次是能被明确坐实的一次。

后续硬规则

以后凡是涉及 Chrome 自动化，一律遵守下面几条：

  1. 不对真实日用 Chrome Profile 做自动化。
  2. 不为了接管浏览器而强杀正在运行的 Chrome。
  3. 不在真实 Profile 上使用 --disable-sync、远程调试、临时实验参数。
  4. 需要调试扩展时，只用独立的临时 user-data-dir 或专门的测试 Profile。
  5. 需要写入扩展账号数据时，优先走导入导出、存储层写入或专用接口，不再劫持真实浏览器会话。
  6. 任何浏览器级实验前，先备份 Local State、Preferences、Secure Preferences、Sessions。

这事的本质不是 Chrome 不稳定，而是我把“生产环境”当“实验环境”用了。
记下来，免得下次再犯。