准确捕获QuotaExceededError的唯一可靠方式是用try-catch包裹每次setItem操作，因浏览器仅在执行瞬间抛出该异常，且各浏览器错误类型、name和code存在差异，需封装兼容性判定函数并区分场景做降级处理。
准确捕获 QuotaExceededError 不是靠预估容量，而是靠“写入即检测”——浏览器只在 setItem() 执行瞬间抛出该异常，没有前置判断接口，也没有跨浏览器统一的剩余空间读取方式。
用 try-catch 包裹每次 setItem 是唯一可靠方式
必须对每一次写入操作加防护，不能只在初始化或关键节点检查。原因在于：
- localStorage 是同步操作，异常会立即阻断执行流，不捕获就会导致 Uncaught 错误、功能中断甚至白屏
- 不同浏览器抛出的错误构造略有差异：Chrome/Firefox/Edge 通常为
name === "QuotaExceededError"，旧版 Safari 可能是name === "NS_ERROR_DOM_QUOTA_REACHED"或code === 1014 - 仅检查
e.name === "QuotaExceededError"不够健壮，需兼容 DOMException 类型和多种 code 值
精准识别 QuotaExceededError 的判断函数
推荐封装一个类型安全的判定工具，覆盖主流浏览器变体：
function isQuotaExceededError(err) {
return err instanceof DOMException &&
(err.name === 'QuotaExceededError' ||
err.name === 'NS_ERROR_DOM_QUOTA_REACHED' ||
err.code === 22 || // legacy code
err.code === 1014);
}
使用时直接嵌入写入逻辑：
try {
localStorage.setItem(key, JSON.stringify(value));
} catch (e) {
if (isQuotaExceededError(e)) {
console.error('本地存储已达物理上限，触发熔断');
triggerStorageFallback(); // 如降级到 sessionStorage 或内存缓存
return false;
} else {
throw e; // 其他异常（如隐私模式禁用）不吞掉
}
}
熔断后必须区分场景做响应
捕获到异常只是第一步，后续动作决定用户体验是否断裂：
- 若写入的是非关键数据（如页面滚动位置、表单草稿），可静默丢弃并提示用户“本地缓存已满，当前操作未持久化”
- 若写入的是登录态 token 或用户偏好，应立即启用备用通道：优先尝试
sessionStorage（同源同窗口，5MB 独立配额），再 fallback 到内存缓存 + 下次启动重拉 - 严禁在熔断路径中调用
localStorage.clear()—— 它会无差别删除所有键，可能误删 token、主题设置等核心字段 - 可配合轻量级清理策略：比如只删除带
_temp或_draft后缀的键，或按时间戳字段清除 7 天前的缓存项（前提是写入时已规范标记）
避免常见误判陷阱
很多“看似容量不足”的报错其实与物理上限无关：
- 在 Safari 隐私模式下，
localStorage可能被完全禁用，此时抛出的是SecurityError或静默失败，不是QuotaExceededError - 调用
JSON.stringify()本身可能因循环引用或超大对象抛出TypeError，需在外层再包一层 try-catch - 用
TextEncoder.encode(str).length估算字节数仅作参考，UTF-16 编码长度 ≠ 实际存储字节（浏览器内部使用 UTF-8 存储，但无标准 API 暴露） - 不要依赖
localStorage.length或遍历求和来判断是否“快满了”——它既不准，又可能在遍历过程中就因序列化触发异常
