儲存配額和逐出標準
Web 開發者可以使用多種技術在使用者的瀏覽器中儲存資料（即，在使用者檢視網站所用裝置的本地磁碟上）。
不同瀏覽器允許網站儲存的資料量以及達到該限制時刪除資料的機制有所不同。
本文介紹了可用於儲存資料的 Web 技術、瀏覽器為限制網站儲存過多資料而設定的配額，以及必要時刪除資料的機制。
瀏覽器如何分離來自不同網站的資料？
瀏覽器將來自不同網站的資料儲存在不同的位置（也稱為“桶”），以降低使用者在網路上被跟蹤的風險。在大多數情況下，瀏覽器會按源（per origin）管理儲存的資料。
因此，要理解本文，源（origin）這個術語非常重要。源由協議（如 HTTPS）、主機名和埠定義。例如，https://example.com 和 https://example.com/app/index.html 屬於同一個源，因為它們有相同的協議（https）、主機名（example.com）和預設埠。
本文中描述的配額和清除標準適用於整個源，即使該源用於執行多個網站，例如 https://example.com/site1/ 和 https://example.com/site2/。
然而，在某些情況下，瀏覽器可能會決定將一個源儲存的資料進一步劃分到不同的分割槽中，例如當一個源在多個不同的第三方源中的 <iframe> 元素內載入時。但為簡單起見，本文假定資料總是按源儲存。
哪些技術可以在瀏覽器中儲存資料？
Web 開發者可以使用以下 Web 技術在瀏覽器中儲存資料
| 技術 | 描述 |
|---|---|
| Cookie | HTTP Cookie 是一小段資料，Web 伺服器和瀏覽器相互發送，用於在頁面導航之間記住有狀態的資訊。 |
| Web Storage | Web Storage API 提供了網頁儲存純字串鍵值對的機制，包括 localStorage 和 sessionStorage。 |
| IndexedDB | IndexedDB 是一種 Web API，用於在瀏覽器中儲存大量結構化資料，併為其建立索引以實現高效能搜尋。 |
| Cache API | Cache API 為 HTTP 請求和響應物件對提供了一種持久化儲存機制，用於加快網頁載入速度。 |
| 源私有檔案系統（OPFS） | OPFS 提供了一個對頁面源私有的檔案系統，可用於讀寫目錄和檔案。 |
請注意，除上述技術外，瀏覽器還會為一個源在瀏覽器中儲存其他型別的資料，例如WebAssembly程式碼快取。
瀏覽器儲存的資料是否持久？
一個源的資料在瀏覽器中可以透過兩種方式儲存：持久化（persistent）和盡力而為（best-effort）
- 盡力而為（Best-effort）：這是資料預設的儲存方式。只要源的用量低於其配額、裝置有足夠的儲存空間，且使用者沒有透過瀏覽器設定選擇刪除資料，盡力而為的資料就會一直存在。
- 持久化（Persistent）：一個源可以選擇以持久化的方式儲存其資料。以這種方式儲存的資料只有在使用者透過瀏覽器設定選擇刪除時才會被清除。要了解更多資訊，請參閱資料何時會被清除。
預設情況下，源在瀏覽器中儲存的資料是盡力而為的。當使用 IndexedDB 或 Cache 等 Web 技術時，資料會以透明的方式儲存，無需徵求使用者許可。同樣，當瀏覽器需要清除盡力而為的資料時，它也會在不打擾使用者的情況下進行。
如果開發者出於任何原因需要持久化儲存（例如，在構建依賴於未在別處持久化的關鍵資料的 Web 應用時），他們可以使用Storage API的navigator.storage.persist()方法。
在 Firefox 中，當一個網站選擇使用持久化儲存時，會彈出一個 UI 提示框通知使用者，請求其許可。
Safari 和大多數基於 Chromium 的瀏覽器（如 Chrome 或 Edge）會根據使用者與網站的互動歷史自動批准或拒絕請求，並且不會向用戶顯示任何提示。
注意，Chrome 團隊的研究表明，瀏覽器很少會刪除資料。如果使用者經常訪問一個網站，即使是在盡力而為模式下，其儲存的資料被瀏覽器清除的可能性也非常小。
隱私瀏覽
請注意，在隱私瀏覽模式下（在 Chrome 中稱為無痕模式，在 Edge 中稱為 InPrivate），瀏覽器可能會應用不同的配額，並且儲存的資料通常會在隱私瀏覽模式結束時被刪除。
可以儲存多少資料？
Cookie
不同的瀏覽器對於每個源允許的 Cookie 數量以及這些 Cookie 可以在磁碟上使用的空間有不同的規定。雖然 Cookie 對於在瀏覽器和 Web 伺服器之間跨頁面導航保留一些小的共享狀態很有用，但不建議使用 Cookie 在瀏覽器中儲存資料。Cookie 會隨每個 HTTP 請求傳送，因此將本可以使用其他 Web 技術儲存的資料存放在 Cookie 中，會不必要地增加請求的大小。
因為 Cookie 不應用於在瀏覽器中儲存資料，所以這裡不討論 Cookie 儲存的瀏覽器限制。
Web Storage
Web Storage，可以透過window物件的localStorage和sessionStorage屬性訪問，在所有瀏覽器中最多限制為 10 MiB 資料。
瀏覽器每個源最多可以儲存 5 MiB 的本地儲存和 5 MiB 的會話儲存。
一旦達到此限制，瀏覽器會丟擲一個 QuotaExceededError 異常，應使用 try...catch 塊來處理。
其他 Web 技術
使用其他 Web 技術（如 IndexedDB、Cache API 或 File System API（它定義了源私有檔案系統））儲存的資料由每個瀏覽器特有的儲存管理系統進行管理。
該系統管理著一個源使用這些 API 儲存的所有資料。
每個瀏覽器都透過其選擇的任何機制來確定給定源可以使用的最大儲存量。
Firefox
在 Firefox 中，一個源在盡力而為模式下可以使用的最大儲存空間是以下兩者中的較小值：
- 儲存使用者配置檔案的總磁碟大小的 10%。
- 或 10 GiB，這是 Firefox 對屬於同一個eTLD+1 域的所有源應用的組限制。
已獲得持久化儲存許可權的源最多可以儲存總磁碟大小的 50%，上限為 8 TiB，並且不受 eTLD+1 組限制的約束。
例如，如果裝置有一個 500 GiB 的硬碟，Firefox 將允許一個源最多儲存：
- 在盡力而為模式下：10 GiB 的資料，即 eTLD+1 組限制。
- 在持久化模式下：250 GiB，即總磁碟大小的 50%。
請注意，源實際上可能無法達到其配額，因為配額是基於硬碟總大小計算的，而不是當前可用的磁碟空間。這樣做是出於安全原因，以避免指紋識別。
Chrome 及基於 Chromium 的瀏覽器
在基於Chromium 開源專案的瀏覽器中，包括 Chrome 和 Edge，一個源在持久化和盡力而為模式下最多可以儲存總磁碟大小的 60%。
例如，如果裝置有一個 1 TiB 的硬碟，瀏覽器將允許一個源最多使用 600 GiB。
與 Firefox 類似，由於此配額是基於硬碟總大小計算以避免指紋識別，一個源實際上可能無法達到其配額。
Safari
WebKit 對瀏覽器應用和其他可以嵌入 Web 內容的應用（例如，使用 WKWebView 的應用）施加了不同的配額。瀏覽器應用是可以設定為系統預設瀏覽器的應用程式。這包括 Safari 和一些其他基於 WebKit 的第三方瀏覽器。
從 macOS 14 和 iOS 17 開始
- 對於基於 WebKit 的瀏覽器應用，每個源最多可以儲存總磁碟空間的 60% 左右。
- 對於其他嵌入 Web 內容的基於 WebKit 的應用，每個源最多可以儲存總磁碟空間的 15% 左右。如果使用者已將網站作為 Web 應用儲存到主螢幕或程式塢，則它使用與瀏覽器應用相同的源配額（約佔磁碟空間的 60%）。
例如，一臺配備 1 TiB 硬碟的 macOS 裝置將限制 Safari 瀏覽器內每個源的儲存空間約為 600 GiB。而在另一個應用內嵌的 WebView 中執行的源將被分配一個較小的限制，約為 150 GiB。
出於隱私原因，跨源 iframe 有一個單獨的配額，約為其父級配額的 1/10。
與其他瀏覽器一樣，為避免指紋識別，配額強制執行的確切限制可能會有所不同。
WebKit 還強制執行一個總體配額，即所有源儲存的資料總量不能超過瀏覽器應用磁碟大小的 80%，以及顯示 Web 內容的非瀏覽器應用磁碟大小的 20%。
有關 WebKit 儲存策略的更多資訊，請訪問 WebKit 部落格。
在早期版本的 Safari 中，一個源被給予初始的 1 GiB 配額。一旦源達到此限制，Safari 會請求使用者允許該源儲存更多資料。無論源是以盡力而為模式還是持久化模式儲存資料，都會發生這種情況。
注意：在 iOS/iPadOS 上，第三方瀏覽器歷來必須使用 WebKit，因此這些 WebKit 配額也適用於它們以及 Safari。在歐盟地區（iOS 17.4+），Apple 允許使用替代瀏覽器引擎；在這種情況下，將適用這些瀏覽器自身的引擎策略，而非 WebKit 的策略。
在 macOS 上，非 WebKit 瀏覽器（例如 Chromium/Firefox）使用它們自己的儲存策略。
有關歐盟特定資訊的更多詳情，請訪問Apple 開發者支援頁面。
如何檢查可用空間？
Web 開發者可以使用Storage API的navigator.storage.estimate()方法來檢查其源的可用空間以及已被使用的空間。
請注意，此方法僅返回估算的使用值，而非實際值。一個源儲存的某些資源可能來自其他源，瀏覽器在報告總使用值時會有意地對跨源資料的大小進行填充。
當一個源的配額用滿時會發生什麼？
例如，嘗試使用 IndexedDB、Cache 或 OPFS 儲存超過源配額的資料會失敗，並丟擲 QuotaExceededError 異常。
Web 開發者應將寫入瀏覽器儲存的 JavaScript 程式碼包裝在 try...catch 塊中。同時建議在儲存新資料之前透過刪除資料來釋放空間。
資料何時會被清除？
資料清除是瀏覽器刪除一個源所儲存資料的過程。
資料清除可能在多種情況下發生：
- 當裝置儲存空間不足時，也稱為儲存壓力（storage pressure）。
- 當瀏覽器中儲存的所有資料（跨所有源）總量超過瀏覽器願意在裝置上使用的總空間時。
- 對不經常使用的源進行主動清除，這種情況僅在 Safari 中發生。
儲存壓力清除
當裝置儲存空間不足時，也稱為儲存壓力（storage pressure），可能會出現瀏覽器可用空間不足以儲存所有源資料的情況。
瀏覽器使用最近最少使用（LRU）策略來處理這種情況。最近最少使用的源的資料會被刪除。如果儲存壓力持續存在，瀏覽器會繼續處理次近最少使用的源，以此類推，直到問題解決。
此清除機制僅適用於非持久化的源，並會跳過已透過 navigator.storage.persist() 獲得資料持久化許可權的源。
瀏覽器最大儲存空間超限清除
一些瀏覽器定義了它們可以在裝置硬碟上使用的最大儲存空間。例如，Chrome 目前最多使用總磁碟大小的 80%。
這個最大儲存大小意味著，可能會出現所有源儲存的資料總量超過了最大值，而沒有任何一個源超過其自身配額的情況。
當這種情況發生時，瀏覽器會開始清除盡力而為的源，如儲存壓力清除中所述。
主動清除
當開啟跨站跟蹤預防功能時，Safari 會主動清除資料。如果一個源在過去七天的瀏覽器使用中沒有使用者互動（如點選或輕觸），其透過指令碼建立的資料將被刪除。由伺服器設定的 Cookie 不受此清除規則影響。
資料是如何被清除的？
當一個源的資料被瀏覽器清除時，是其所有資料同時被刪除，而不是部分資料。例如，如果該源同時使用了 IndexedDB 和 Cache API 儲存資料，那麼這兩種型別的資料都會被刪除。
僅刪除源的部分資料可能會導致不一致問題。