本指南主要介紹 Workbox v4 中導入的破壞性變更，並舉例說明從 Workbox v3 升級時需要進行哪些變更。
破壞性變更
workbox-precaching
預先快取項目的命名慣例已更新。對於需要修訂資訊的項目 (也就是在預快取資訊清單中含有 revision 欄位的項目)，系統會將該修訂資訊儲存在快取索引鍵中，並附加至原始網址的特殊 __WB_REVISION__ 網址查詢參數中。(先前，這項資訊會使用 IndexedDB 與快取鍵分開儲存)。
開發人員透過 workbox.precaching.precacheAndRoute() 使用預先快取功能 (這是最常見的用途)，因此不需要變更服務工作程式設定；升級至 Workbox 4.0 後，使用者的快取素材資源會自動遷移至新的快取鍵格式，且日後會以與先前相同的方式繼續提供預先快取的資源。
直接使用快取金鑰
部分開發人員可能需要在 workbox.precaching.precacheAndRoute() 的內容之外，直接存取友善快取項目。舉例來說，您可以先行快取圖片，以便在無法從網路擷取實際圖片時，將該圖片用作「備用」回應。
如果您以這種方式使用預先快取的素材資源，從 Workbox 4 版開始，您需要採取額外步驟，將原始網址轉譯為可用於讀取快取項目的對應快取鍵。方法是呼叫 workbox.precaching.getCacheKeyForURL(originURL)。
舉例來說，如果您知道 'fallback.png' 是友善快取：
const imageFallbackCacheKey =
workbox.precaching.getCacheKeyForURL('fallback.png');
workbox.routing.setCatchHandler(({event}) => {
switch (event.request.destination) {
case 'image':
return caches.match(imageFallbackCacheKey);
break;
// ...other fallback logic goes here...
}
});
清理舊的預快取資料
在 Workbox 4.0 中對預先快取功能所做的變更，意味著由舊版 Workbox 建立的舊版預先快取內容將無法相容。根據預設，這些資源會維持原樣，如果您從 Workbox 3 升級至 Workbox 4，就會得到所有預先快取資源的兩個副本。
為避免這種情況，您可以直接在服務工作站中新增對 workbox.precaching.cleanupOutdatedCaches() 的呼叫，或者在 GenerateSW 模式下使用建構工具時，設定新的 cleanupOutdatedCaches: true 選項。由於快取清除邏輯會根據快取命名慣例運作，以便找出較舊的預快取，且開發人員確實可以選擇覆寫這些慣例，因此我們基於安全考量，並未預設啟用這項功能。
如果開發人員在使用這項功能時遇到任何問題 (例如刪除作業出現誤判)，歡迎與我們聯絡。
參數大寫
兩個可傳遞至 workbox.precaching.precacheAndRoute() 和 workbox.precaching.addRoute() 的選用參數已重新命名，以便統一整體大寫慣例。ignoreUrlParametersMatching 現已改名為 ignoreURLParametersMatching，cleanUrls 現已改為 cleanURLs。
Workbox 策略
在 workbox-strategies 中建立處理常式例項的方法大致相同，有兩種方式。我們即將淘汰工廠方法，改為明確呼叫策略的建構函式。
// This factory method syntax has been deprecated:
const networkFirstStrategy = workbox.strategies.networkFirst({...});
// Instead, use the constructor directly:
// (Note that the class name is Uppercase.)
const networkFirstStrategy = new workbox.strategies.NetworkFirst({...});
雖然工廠方法語法會繼續在 v4 中運作，但使用時會記錄警告，因此我們建議開發人員提前進行遷移，以免在日後的 v5 版本中移除支援。
workbox-background-sync
workbox.backgroundSync.Queue 類別已重寫，讓開發人員更有彈性地掌控要求如何加入至佇列並重播。
在 v3 中，Queue 類別只有一種方法可將要求新增至佇列 (addRequest() 方法)，但無法修改佇列或移除要求。
第 4 版已移除 addRequests() 方法，並新增下列類似陣列的方法：
pushRequest()popRequest()shiftRequest()unshiftRequest()
在 v3 中，Queue 類別也接受了幾個回呼，可讓您觀察要求重播的時間 (requestWillEnqueue、requestWillReplay、queueDidReplay)，但大多數開發人員發現，除了觀察之外，他們還想控制佇列的重播方式，包括動態修改、重新排序，甚至取消個別要求的功能。
在 v4 中，這些回呼已移除，改為使用單一 onSync 回呼，瀏覽器每次嘗試重播時都會叫用此回呼。根據預設，onSync 回呼會叫用 replayRequests()，但如需進一步控管重播程序，可以使用上述類似陣列的方法，按照您需要的方式重播佇列。
以下是自訂重播邏輯的範例：
const queue = new workbox.backgroundSync.Queue('my-queue-name', {
onSync: async ({queue}) => {
let entry;
while ((entry = await this.shiftRequest())) {
try {
await fetch(entry.request);
} catch (error) {
console.error('Replay failed for request', entry.request, error);
await this.unshiftRequest(entry);
return;
}
}
console.log('Replay complete!');
},
});
同樣地，workbox.backgroundSync.Plugin 類別會接受與 Queue 類別相同的引數 (因為它會在內部建立 Queue 例項)，因此會以相同方式進行變更。
工作箱效期
npm 套件已重新命名為 workbox-expiration，與其他模組使用的命名慣例一致。這個套件的功能與已淘汰的舊版 workbox-cache-expiration 套件。
workbox-broadcast-update
npm 套件已重新命名為 workbox-broadcast-update，以符合其他模組的命名慣例。這個套件的功能與舊版 workbox-broadcast-cache-update 套件相同，但後者現已淘汰。
workbox-core
在 Workbox v3 中，您可以透過 workbox.core.setLogLevel() 方法控制記錄層級的詳細程度，並傳遞 workbox.core.LOG_LEVELS 列舉中的其中一個值。您也可以透過 workbox.core.logLevel 讀取目前的記錄層級。
在 Workbox v4 中，由於所有新版開發人員工具現在都提供豐富的記錄篩選功能，因此已移除所有這些功能 (請參閱 Chrome 開發人員工具的篩選控制台輸出內容)。
工作箱 Sw
先前直接在 workbox 命名空間 (對應至 workbox-sw 模組) 公開的兩個方法，現在已改為移至 workbox.core。workbox.skipWaiting() 已變更為 workbox.core.skipWaiting()，workbox.clientsClaim() 也已變更為 workbox.core.clientsClaim()。
建構工具設定
可傳遞至 workbox-cli、workbox-build 或 workbox-webpack-plugin 的部分選項名稱已變更。凡是選項名稱中使用「Url」的情況，都已淘汰，改用「URL」。也就是說，系統會優先採用下列選項名稱：
dontCacheBustURLsMatchingignoreURLParametersMatchingmodifyURLPrefixtemplatedURLs
這些選項名稱的「Url」變化版本仍可在 v4 中運作，但會顯示警告訊息。我們建議開發人員在 v5 版推出前完成遷移。
新功能
workbox-window
新的 workbox-window 模組可簡化服務工作者註冊和偵測更新的程序，並提供在服務工作者執行的程式碼與在網路應用程式 window 情境執行的程式碼之間的標準通訊方式。
雖然 workbox-window 為選用項目，但我們希望開發人員會覺得它很實用，並考慮遷移部分手寫邏輯，以便視情況使用。如要進一步瞭解如何使用 workbox-window，請參閱模組指南。
遷移作業範例
如需從 Workbox v3 遷移至 v4 的實際範例，請參閱這項提取要求。
取得說明
我們預期大部分遷移作業都會很簡單。如果您遇到本指南未提及的問題，請在 GitHub 上開啟問題通知我們。