javascript mock测试中模拟存储配额超限，核心是主动触发storage api抛出quotaexceedederror异常；常用方式为jest.spyon(localstorage, 'setitem').mockimplementation(() => { throw new domexception('quota exceeded', 'quotaexceedederror'); })。
在 JavaScript Mock 测试中模拟浏览器存储空间配额超限，核心是**主动触发 Storage API 抛出 QuotaExceededError 异常**——这是浏览器在 localStorage、sessionStorage 或 IndexedDB 写入超出限制时原生抛出的标准 DOMException。
直接覆盖 Storage 方法并抛错
最常用、最轻量的方式是临时替换 localStorage.setItem（或 sessionStorage.setItem），使其在特定条件下抛出配额错误：
- 在测试前用
jest.spyOn(localStorage, 'setItem').mockImplementation(() => { throw new DOMException('Quota exceeded', 'QuotaExceededError'); }) - 若需更真实地模拟“写入中途失败”，可控制抛错时机，例如：只在第 6 次调用时抛错，验证应用的降级逻辑（如 fallback 到内存缓存）
- 注意：必须在测试环境（如 Jest）中执行，且确保未启用持久化存储策略（如
navigator.storage.persist()）干扰行为
Mock IndexedDB 配额超限（更贴近真实场景）
IndexedDB 的配额机制更复杂，但也是前端超限的高发区。可通过 mock indexedDB.open 返回的 request 对象来模拟失败：
- 创建一个伪造的
IDBRequest实例，将其error属性设为new DOMException('Maximum quota exceeded', 'QuotaExceededError') - 将该 request 的
onerror触发，或直接设置request.result为 undefined 并调用request.onerror - 推荐使用
fake-indexeddb库配合 jest，在内存中运行完整 IDB 行为，并通过手动填满数据库触发真实配额逻辑（需预估容量阈值）
避免常见误区
有些做法看似合理，实则无效或不可靠：
- 不要尝试修改
localStorage.length或伪造localStorage对象的内部容量——浏览器不检查这个，也不会因此抛错 - 不要依赖
try/catch捕获“写入后读取失败”来反推配额超限——这可能是其他原因（如私密模式禁用 storage） - 不要在非浏览器环境（如 Node.js）下 mock 浏览器 storage——应确保测试运行在 JSDOM 或真实浏览器环境（如 Puppeteer）中
关键是让被测代码真正走到 catch(e) { if (e.name === 'QuotaExceededError') { ... } 分支里，这样才能验证你的降级、清理或提示逻辑是否生效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
