先说一个让不少PWA（渐进式Web应用）开发者头疼的场景：Service Worker的缓存写入失败，Cache API抛出QuotaExceededError，或者你打开 chrome://quota-internals 发现配额显示为0。别急着怀疑代码写错了——很可能是当前页面的缓存配额已被耗尽，或者压根就没正确分配。要准确定位实际可用空间和已用额度，需要从三个不同维度交叉验证。下面这四步走下来，基本就能把问题摸清楚，帮你高效排查Chrome缓存配额瓶颈。
通过Application面板快速查看当前源的缓存用量与配额
这一步最简单，打开开发者工具就能看到总存储概览，适合先摸个底，快速了解Service Worker缓存所处的存储环境。
1. 在目标网页按 Ctrl+Shift+I（Windows/Linux）或 Cmd+Option+I（macOS）打开开发者工具。
2. 切换到 Application 选项卡 → 左侧展开 Storage → 点击 Usage 子项（如果没显示，刷新一次页面即可）。
3. 右侧会列出当前 origin 的总存储用量（比如“Used: 84.2 MB”）和浏览器估算的硬性配额（比如“~105 MB”）。注意：这个数值是所有本地存储类型（包括Cache Storage、IndexedDB、localStorage等）的合计配额，并不是单独给Service Worker缓存分配的额度。若想精确了解缓存专属空间，需结合后续步骤。
4. 如果Usage下方完全没有数字，说明Chrome还没完成配额评估——这时候需要去 chrome://quota-internals 手动触发一下查询，以确认配额分配状态。
用chrome://quota-internals精确检查Cache Storage专属配额与持久化状态
这个内部页面直接暴露了QuotaManager底层策略，能告诉你Service Worker缓存到底被分配了多少空间、是否启用了持久化权限、以及当前使用量是否真实。这是排查QuotaExceededError的核心手段。
方法一：直接查询当前站点
1. 地址栏输入 chrome://quota-internals/ 并回车。
2. 在 Origin 输入框中填入完整协议+域名，比如 https://example.com（https://不能漏，否则查不到）。
3. 点击 Query 按钮，等待结果返回。
4. 在表格中找到对应行，重点关注三列：Usage（当前Cache Storage实际占用的字节数）、Quota（分配给这个origin的总配额）、Persistent（是否已经获得持久化存储授权）。如果 Persistent 显示 false，说明即使你调用了 navigator.storage.persist()，用户也还没有点击“允许”按钮，此时配额仍受临时存储限制。
方法二：全局扫描异常配额
1. 不填Origin，直接点 Query，页面会列出全部已注册origin的配额快照。
2. 按 Usage 列排序，找出占用接近 Quota 的站点——这些就是最可能触发QuotaExceededError的高危对象。
3. 如果某个站点的 Quota 显示为 0，大概率是注册时域名拼写错误、HTTPS没有启用，或者被企业策略强制限制了。这时候需要检查Service Worker注册脚本中的 scope 参数是否合法，以及HTTPS是否已正确配置。
在控制台执行navigator.storage.estimate()获取动态配额基准
这是唯一能在运行时获得Service Worker缓存专属配额的方法，结果最贴近真实场景，不过依赖页面已经加载并执行过storage API。使用它能动态评估当前源的可用空间。
第一步：确认页面已加载Service Worker脚本
在Application → Service Workers面板中，确保状态栏显示“Ready”或“Active”，否则 navigator.storage 不可用。
第二步：打开Console面板，粘贴并执行以下代码：
navigator.storage.estimate().then(estimate => { console.log('已用:', estimate.usage, '字节'); console.log('总额度:', estimate.quota, '字节'); console.log('可用率:', ((estimate.quota - estimate.usage) / estimate.quota * 100).toFixed(1) + '%'); });
第三步：观察输出结果。 如果 estimate.quota 小于 10MB，说明Chrome仍然按照默认的BestEffort策略分配（通常是磁盘空闲空间的10%～20%，且上限约10MB）；如果大于 100MB，大概率已经通过 navigator.storage.persist() 获得了持久化权限，或者启动参数 --unlimited-storage 生效。若结果符合预期，可进一步交叉验证。
⚠️ 注意：这个API在部分旧版Chrome（< v95）中可能返回 undefined，这种情况下请改用 chrome://quota-internals 查询。
通过chrome://settings/siteData验证整站存储占用真实性
这个设置页面提供的是操作系统级别的磁盘占用统计，数值比Application面板更精确，适合用来交叉验证 quota-internals 中 Usage 是否可信，避免因缓存机制差异导致的误判。
1. 地址栏输入 chrome://settings/siteData 并回车。
2. 在搜索框中输入目标网站域名（比如 example.com），确保勾选了“显示详细信息”。
3. 找到对应条目后，右侧“存储”列显示的 KB/MB 数值，就是这个 origin 在本地磁盘上实际占用的空间，包含 Cache Storage + IndexedDB + localStorage + Cookies 全部内容。
4. 如果这里显示 92 MB，而 chrome://quota-internals 中 Usage 只有 12 MB，说明剩下的 80 MB 来自 IndexedDB 或其他存储机制——这时候应该返回 Application 面板检查 IndexedDB 数据库的大小，而不是只盯着Cache Storage。综合以上四步，即可全面诊断Chrome缓存配额问题，确保Service Worker稳定运行。
