Chrome 扩展 Manifest V3 迁移实录：我是怎么把云同步塞进严格限制里的
Manifest V3（MV3）不只是语法更新，它彻底颠覆了浏览器扩展的开发方式。
简单的工具迁移不难，但如果要做的是一个离线优先、持续与 Google Drive 通信的应用，MV3 会逼你抛弃所有关于状态管理、网络中断和依赖处理的既有经验。以下是我在 MV3 Service Worker 的严格限制下，让云同步引擎稳定运行所做的权衡。
一、内存状态已死，必须磁盘优先
在 MV2 时代，把同步队列存在后台脚本的变量里是标准操作。但 MV3 可以随时杀死 Service Worker 来释放内存——用户裁剪网页时 worker 刚好被销毁，上传还没完成，数据就永远丢失了。
现在必须采用严格的磁盘优先模型。chrome.storage.local 成为唯一的事实来源。
我的做法是：用户任何操作——裁剪文本、输入笔记、使用语音输入——都立即写入本地存储。向云端同步只是后台的一个"事后诸葛亮"。Service Worker 本身不持有任何状态，所以浏览器可以随时唤醒它，让它检查本地存储中待同步的内容，发起上传，然后销毁。全程不丢数据。
二、离线重连的合并策略
永远不要信任网络，尤其是运行在不稳定 Wi-Fi 或笔记本休眠场景下的浏览器扩展。
用户离线时，扩展立即停止同步并将状态排队到本地。真正的麻烦在于重新上线——如果盲目地把本地变更推送到云端，可能会覆盖用户从另一台设备做出的更新。
我写了一个脚本来手动合并冲突。连接恢复后，代码从 Google Drive 的 appDataFolder 拉取现有 JSON，然后将本地笔记和远程笔记合并到一个 Map 中。由于笔记 ID 本质上就是时间戳，排序非常简单，自然也能处理重复。合并完成后再把整个数组一次性上传回 Google Drive。做法有点 hack，但完全可以避免意外覆盖——即便 Chrome 正好在同步过程中关闭后台脚本也不受影响。
三、抛弃 Google SDK，改用原生 Fetch
我做的另一个重大取舍是彻底去掉官方 Google API 客户端。
SDK 确实让开发更简单，但体积巨大。把庞大的依赖树塞进 MV3 Service Worker 会拖慢执行时间、增大包体积，完全违背新清单的性能目标。
我选择严格使用原生 fetch API 来调用 Google Drive v3 REST API，让扩展保持极快的速度和轻量的体积。代价是：如果想在一个请求中同时上传元数据和文件内容，必须手写 multipart/related HTTP 请求体。
这意味着要用原生 JavaScript 手动处理字符串边界，并确保回车换行（\r\n）精确无误。
手动写原始 HTTP 请求确实很烦人，尤其是对比 SDK 里 drive.files.create() 一行搞定的方式。但去掉所有依赖重量后，扩展的响应速度是立竿见影的，这个取舍我愿意再做一次。
总结
Manifest V3 最初看起来限制很多，但把它当作硬约束反而能逼出更好的设计。接受状态会消亡、写防御性离线检查、抛弃重量级库——完全可以构建出真正像浏览器原生一样顺滑的云端集成。
评论