应先用 try...catch 捕获 quotaexceedederror 避免流程中断，再通过 encodeuricomponent(json.stringify(localstorage)).length 估算用量，按前缀分类清理非关键 key，溯源并优化持续写入逻辑。
localStorage.setItem 报 QuotaExceededError 怎么办
说明：这不是代码写错了，是浏览器给你的 localStorage 配额用光了。Chrome/Firefox 通常限制在 5–10MB，Safari 更严（iOS 上可能仅 2.5MB），超出后 setItem 直接抛 QuotaExceededError，页面逻辑卡住。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 先用
try...catch包住写入操作，避免未捕获异常中断流程 - 检查当前用量：
encodeURIComponent(JSON.stringify(localStorage)).length（粗略字节数，注意 Unicode 字符占多字节） - 别依赖
localStorage.length——它只返回 key 的数量，不反映实际存储体积 - 写入前可预估大小：对值做
JSON.stringify(val).length，叠加已有估算值判断是否接近上限
怎么安全清空不用的 localStorage key
说明：直接 localStorage.clear() 很危险——可能误删登录态、用户偏好等关键数据。得按需清理，且要避开正在使用的 key。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给 key 加统一前缀，比如
app_cache_、temp_search_，清理时用for (let i = 0; i 遍历 <code>key(i)，匹配前缀再删 - 不要用
for...in遍历localStorage——它会遍历原型链上的属性，不可靠 - 清理后建议触发一次
storage事件监听（如果其他 tab 依赖同步），但注意本页不会收到自身触发的事件 - 若存的是 JSON 字符串，删除前可加校验：
try { JSON.parse(localStorage.getItem(key)) } catch(e) { localStorage.removeItem(key); }，清理损坏项
localStorage 持久化数据该不该压缩
说明：压缩能延缓配额耗尽，但 JS 压缩（如 LZUTF8、pako）本身有开销，且移动端解压可能卡顿。不是所有场景都值得上。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 纯文本类缓存（日志、搜索历史、表单草稿）压缩收益明显；JWT token、简单开关状态（
"true"）压缩后反而更大 - 优先用
JSON.stringify(obj, null, 0)去掉空格，比默认格式节省 15–30% 体积 - 真要压缩，选轻量库：pako 的
pako.deflate()+atob()编码，但注意 iOS Safari 对Uint8Array支持较晚（iOS 13+ 稳定） - 压缩后务必存原始长度和压缩标识，比如
{"z":1,"d":"eJ..."}，否则未来升级或调试时无法识别
localStorage 满了但不知道谁占的——怎么查
说明：没有浏览器原生“磁盘分析”功能，得手动探测。DevTools 的 Application → Storage → Local Storage 只显示 key 名和值截断，看不出真实体积。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在 Console 运行这段检测脚本：
Object.keys(localStorage).forEach(k => console.log(`${k}: ${unescape(encodeURIComponent(localStorage.getItem(k))).length} bytes`)) - 重点关注长 value 的 key，尤其是存了 base64 图片、大数组 JSON、未分页的列表数据
- 某些 SDK（如 Sentry、Firebase Analytics）会静默写入大量调试信息，检查是否有
sentry_、fire...类 key - 如果是 PWA，留意
workbox-*开头的 key——Workbox 默认用localStorage存路由缓存策略，容易堆积
真正麻烦的不是“怎么清”，而是“清完立刻又满”——说明业务逻辑在持续无节制写入。得回溯源头：是不是搜索结果没分页就全塞进缓存？是不是每次点击都追加日志而不轮转？配额问题本质是数据生命周期管理没到位。
