Chrome 浏览器的存储空间限制

Question

什么是软限制（用户需要允许超过该限制）？ 什么是硬限制（允许的最大值）。

Answer 1

警告 - 此信息已过时 - 请参阅下面的 other answer。

Chrome 在达到 QUOTA_ERR 之前有 5mb 的软限制。 Here's a MDN reference 这个事实。

spec 提到了 QuotaExceededError，但似乎没有说明什么时候应该抛出它。

QuotaExceededError 操作失败，因为没有足够的 剩余存储空间，或已达到存储配额且用户 拒绝为数据库提供更多空间。

我没有听说过硬限制，在我自己的开发中也没有达到。在您到达之前，性能应该会向南走很远。

Answer 2

2020 年 5 月更新：Chrome 现在允许源使用 60% 的存储设备空间（真正的细节：“存储设备”是包含 chrome 配置文件目录的分区）。在此处更新文章https://web.dev/storage-for-the-web/#how-much

---

经验法则是用户硬盘驱动器上可用空间的 6%（2015 年 7 月编辑：为 10%），如果您的源使用 websql、appcache 或文件系统 API，则更少。提到 5mb 的 MDN 文档已过时并已更新。有关当前政策的血腥细节在这里：https://developer.chrome.com/apps/offline_storage

注意一些烦人的细微之处：

1. indexeddb 没有 PERSISTENT 存储，只有上面链接中关于 TEMPORARY 的内容适用。
2. 一旦您的源用尽了它在池中的份额，indexeddb 事务将毫无帮助地中止，而没有真正的原因说明。到目前为止，确定配额不足的唯一方法是使用queryUsageAndQuota 检查剩余空间。希望将来的 chrome 版本能在这些情况下正确填写 IDBTransaction.error。 编辑：chrome 26 现在用 QuotaExceededError 正确填写 IDBTransaction.error。
3. 目前没有 API 可以为 indexeddb 请求更多存储空间。

Answer 3

最小或软限制为 5MB - 浏览器将请求存储数据的权限。 最大存储空间是硬盘的限制，因为所有数据都本地存储在您的机器磁盘上。 基本上，如果您有 20GB 的可用存储空间，那么您可以将所有存储空间用于 IndexedDB。

Answer 4

在 chrome>dev tools(F12)>console 中使用以下代码检查配额

// Request storage usage and capacity left
window.webkitStorageInfo.queryUsageAndQuota(webkitStorageInfo.TEMPORARY, 
//the type can be either TEMPORARY or PERSISTENT
function(used, remaining) {
  console.log("Used quota: " + used + ", remaining quota: " + remaining);
}, function(e) {
  console.log('Error', e); 
} );

Answer 5

IndexedDB 从 Google Chrome 中的“TEMPORARY”存储中获得内存。 Chrome 上的临时存储空间的默认配额为可用磁盘空间的 50%，其中 20% 可供您的离线应用使用。为临时存储请求更多配额没有任何作用。

根据上述情况，您的问题的答案是：

1. IndexedDB（在 Chrome 浏览器上）无需请求即可使用存储。 （知道它是从临时存储中分配的）
2. 请求超过 TEMPORARY 存储限制（50% 的 20%，如上所述）将不会分配任何内容。

您可以使用Browser Storage Abuser 工具（在this HTML5Rocks 文章中引用，该文章记录了不同浏览器的结果）来确定您正在运行的 Chrome 上的可用临时存储。

我没有足够的声誉来发布更多链接，但上面关于配额研究的 HTML5Rocks 文章有足够的详细信息来帮助您确定适当的存储类型（临时或持久）和适当的存储机制（如果您不一定IndexedDB 归零），因为它可能适合您的应用程序。

Answer 6

问题是关于 Chrome 并标记为 IndexedDB。而且我认为它是关于网站，而不是 Chrome 扩展程序或应用程序（允许无限存储 IndexedDB）。

对于网站，IndexedDB 是一个用于 Chrome 临时存储的 API (source)。所以问题是关于 Chrome 中的临时存储配额。

在 Chrome 67 中，配额行为发生了变化，除了 a bug report 之外，这并没有真正记录在案。综合来看，目前的配额行为是：

• 在 Chrome 普通模式

  • 对于离线 API（应用缓存、文件系统、IndexedDB、WebSQL）：

    如果达到“应保持可用”值，则一个来源（“站点”）的配额将为零。 “应该保持可用”值与在大容量存储上保持空闲的空间有关。从 Chrome 67 开始，它是“2 GiB”和“大容量存储总容量的 10%”（source）的较低值。一旦达到此限制，对临时存储的额外写入将失败，但不会删除临时存储中的现有数据。

    如果尚未达到“应该保持可用”值，则配额将为共享池的 20% (source)。这（可能）意味着“Chrome 已经保存了临时存储中所有数据的 20%，加上 Chrome 可以保存到本地存储而不达到 '应该保持可用' 值的所有数据”。

  • 对于 Web 存储 API（LocalStorage、SessionStorage 等）：5 MiB 已修复 (source)；我不知道这是否受到上面记录的“应该保持可用”限制的影响。

• 在 Chrome 隐身模式

  • 对于离线 API（应用缓存、文件系统、IndexedDB、WebSQL）：大约100 MiB 固定，无论大容量存储上的可用空间如何 (source)。
  • 对于 Web 存储 API（LocalStorage、SessionStorage 等）：5 MiB 已修复 (source)。