北京
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、從樂觀推送到保守合并的全盤重構。好消息是，改完之后，擴展確實更快、更穩、更可控了。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
