Chrome 多账号共享扩展：先别造新工具

几个 Chrome 个人资料分别登录不同的 Google 账号，却希望共享其中一部分扩展；其他扩展仍由各个环境自己决定。问题很小，但处理不好，会把浏览器账号、扩展权限和配置数据混在一起。

最初想到的办法是维护一个安装了常用扩展的“统一账号”：在目标个人资料里临时登录它，等扩展同步下来，再退出并换回原账号。这个思路借用了 Chrome 已有的同步功能，但不是不同账号之间真正的选择性同步。本次只做了文档和工具调研，没有在本机验证这套账号切换流程。

先分清要同步什么

Chrome 的 Profile（浏览器个人资料）与网页里登录的 Google 账号不是一回事。Chrome 原生可以把扩展信息保存到 Google 账号，供使用同一账号的环境获取；本轮查到的官方功能里，没有面向普通用户的“多个不同账号共同订阅一份扩展子集，并保留各自排除项”的直接入口。

这里也不追求复制整套浏览器。需求只涉及扩展安装清单：哪些扩展应该出现在当前个人资料中、哪些已经安装、哪些明确不需要。扩展内部设置、登录状态、付费授权不在范围内。

临时换账号的问题是边界不清。扩展可能与账号数据关联，也可能只保留在本地；退出时是否移除、换回原账号后是否自动保存到该账号，不能一概而论。更重要的是，同步并非一个天然的“只从统一账号下载、不向它写入”的单向复制流程。为了装几个扩展反复改动浏览器登录身份，风险与操作成本都偏高。

本轮先对照 Chrome 帮助和扩展管理 API，再查商店里的清单迁移与扩展管理工具，重点看三件事：能否识别缺失项、能否只安装想要的项目、是否要求切换 Google 账号。

Extensions Syncer 最贴近这项需求。来源个人资料导出 JSON 清单，目标个人资料导入后查看“已安装 / 未安装”，再点击需要的扩展前往商店安装。省去逐个搜索，但不等于自动安装。
Extension Manager 更偏日常管理：清单导入导出、分组启停、按规则切换状态。如果只是迁移安装清单，未必需要它的全部能力。
Chrome 原生同步适合在同一账号的设备之间延续扩展环境，不直接解决不同账号共享部分扩展的问题。

这里有一条明确的技术边界：普通扩展可通过 chrome.management 查看和管理已安装扩展，但公开接口没有通用的“静默安装其他扩展”方法。Chrome 旧的内联安装接口也已移除。所以商店中的“批量导入”，通常指批量导入清单，安装动作仍需要用户确认。

第一，只同步清单，不冒充自动安装器。记录扩展 ID、来源商店和目标状态，提供差异比较与正确的商店入口；安装完成后重新检查结果。不要用直接修改浏览器配置文件来绕过确认。

第二，允许每个个人资料保留例外。假设公共集合是 A、B、C，工作环境需要全部，私人环境只要 A、B。私人环境排除 C 后，下次导入不应反复催装；公共集合删掉 C，也不应自动卸载已经安装的 C。公共清单负责“推荐安装什么”，不强行接管所有本地选择。

第三，把信任成本压到最低。扩展清单可以本地保存和交换；不碰 Cookie、网页内容与其他扩展的登录数据。即使未来用 GitHub 或其他服务订阅清单，也必须把可分享的清单与访问令牌分开，不能让导出配置顺手带走密钥。

如果只是偶尔新建一个 Chrome 个人资料，现成的导入工具很可能已经够用。只有公共集合经常变动、手动导入仍有明显负担时，才值得增加“订阅公共清单＋个人排除规则”。第一版不需要服务器、团队账户、版本锁定或配置迁移。

先用两个测试个人资料验证：来源有 A、B、C，目标已有 A 和一个独有的 D；目标只补装 B、明确排除 C。验收标准是 D 不受影响、C 不被反复要求安装、第二次导入不重复操作。若现成工具能完成，就停止开发。

真要做成产品，也先只支持 Chrome。Microsoft Edge 对 Chrome 扩展有较好的代码兼容基础，可以作为第二阶段；Firefox 和 Safari 不宜在尚未验证核心需求时一起纳入。浏览器越多，扩展标识、商店、管理 API 与用户授权的差异越需要维护。

这轮调研的决定是暂不立项：先用已有工具验证实际摩擦，再决定有没有必要做“跨个人资料共享公共扩展集”。查到的功能来自官方文档和商店说明，不代表已安装试用，更不构成第三方扩展的安全审计。

写作说明：GPT-6 根据官方文档和商店资料起草；相关工具未安装实测。