重写谷歌云同步：我在MV3服务线程里踩的坑

Chrome的Manifest V3（MV3）上线后，很多开发者以为只是改改配置文件的语法。真动手才发现，这东西把整个浏览器扩展的开发逻辑连根拔了。简单工具倒还好，但如果你在做一款离线优先、还要实时同步谷歌云盘的应用，MV3会逼你把状态管理、网络容错、依赖加载这些老经验全部推翻重来。

我花了三个月，把一个原本基于MV2的云同步引擎硬塞进MV3的Service Worker里。以下是三个不得不做的核心改造，以及背后的代价。

第一：内存状态必须死

MV2时代，后台脚本里挂个变量存同步队列是标准操作。MV3直接断了这条路——浏览器随时会杀掉Service Worker回收内存。用户刚剪完网页内容，Worker一死，数据就没了。

唯一的解法是彻底转向磁盘优先模型。chrome.storage.local成了唯一可信的数据源。我重写了整个应用逻辑：任何用户动作——剪贴文本、输入笔记、语音录入——第一时间落盘本地存储。云同步被降级为纯后台任务，Worker被唤醒后查本地队列、发请求、再被杀掉，全程不持有任何内存状态。

第二：离线断网的合并难题

网络不可靠是浏览器扩展的常态，尤其是笔记本合盖、Wi-Fi跳变的时候。离线时暂停同步、本地排队很简单，真正的坑在恢复连接之后。

如果无脑把本地改动推上云端，可能覆盖掉用户另一台设备上的更新。我手写了一个合并脚本：联网后先从Drive的appDataFolder拉取远端JSON，把本地笔记和远端笔记丢进一个Map里。由于笔记ID本质是时间戳，排序去重天然简单。合并成单一数组后再上传回谷歌。这套土办法能防住意外覆盖，哪怕Chrome中途杀掉后台脚本也不怕丢数据。

第三：砍掉谷歌SDK，手写HTTP

这是代价最大的决定——完全移除官方Google API客户端。

SDK确实省事，但依赖树太庞大。塞进MV3 Service Worker会拖慢执行、撑爆包体积，直接违背MV3的性能设计目标。我改用原生fetchAPI直接调用Google Drive v3 REST接口，扩展体积骤减、启动飞快。

代价是手工拼装multipart/related请求体。要在纯JavaScript里处理字符串边界、构造符合RFC标准的HTTP载荷，才能把元数据和文件内容一次性传上去。代码丑了很多，但每毫秒都在自己掌控中。

MV3不是升级，是范式迁移。它用强制性的资源限制，逼开发者把"随时可能被杀"作为架构的第一假设。对于云同步这类有状态、长连接的场景，这意味着从内存到磁盘、从SDK到裸HTTP、从乐观推送到保守合并的全盘重构。好消息是，改完之后，扩展确实更快、更稳、更可控了。