localstorage 在高频、大数据量场景下易引发卡顿，因其同步阻塞主线程，实测需聚焦首屏写入、高频事件、大对象序列化三类场景，并结合 performance.now()、长任务分析、设备降速与数据量对比验证；应优化写入策略、控制数据体积（超100kb改用indexeddb），并测试quotaexceedederror及禁用降级等容错能力。
localStorage 的读写性能不是“够用就行”，而是容易在高频、大数据量场景下成为页面卡顿的隐形推手。它快在简单，慢在同步阻塞——每次 setItem 或 getItem 都会暂停主线程，等磁盘 I/O 完成，这点必须实测验证，不能凭经验判断。
明确测试目标：别只测“能不能存”，要测“会不会拖慢”
性能测试的核心不是验证 localStorage 是否可用，而是确认它在真实业务路径中的影响。重点关注三类典型场景：
- 首屏关键路径中写入：比如页面加载后立即存用户行为或性能指标，此时主线程本就紧张，一次 setItem 可能延迟渲染 20–50ms；
- 高频事件触发写入：如滚动监听中每滚动一次就存位置，若不做节流，1 秒内可能触发数十次同步写入，直接导致掉帧；
- 大对象序列化与反序列化：存一个 500KB 的配置数组时，JSON.stringify 和 JSON.parse 本身就会消耗 10–30ms，再加上磁盘写入，总耗时可能超 60ms。
实测方法：用 Performance.now() + 真机环境验证
避免用 console.time 这类粗粒度工具，推荐组合使用：
- 用 Performance.now() 包裹关键操作，精确到微秒级；
- 在 Chrome DevTools 的 Performance 面板 录制完整页面加载流程，观察 setItem 是否出现在长任务（Long Task）中；
- 模拟低端设备：在 DevTools 中启用 “Throttling → 4x slowdown” 和 “Simulate slow network”，放大 localStorage 的阻塞效应；
- 对比不同数据体积：分别测试存 1KB、100KB、1MB 数据的 setItem 耗时，画出增长曲线——通常超过 200KB 后耗时会非线性上升。
数据结构与写入策略直接影响性能表现
同样的存储需求，设计不同，性能差异可达数倍：
- 避免逐字段更新：不要对同一 key 频繁调用 setItem({a:1})、setItem({b:2})，应合并为一次写入 setItem(JSON.stringify({a:1,b:2}))；
- 用增量结构替代全量覆盖：例如性能统计场景，先读取已有 stats 对象，仅修改需更新字段（如 stats.errors++），再整体写回，比每次都生成新对象更轻量；
- 写入时机比写入内容更重要：监听 beforeunload 或 visibilitychange 时保存快照，比 onload 后立刻写入更安全且不干扰首屏；
- 小数据可内存暂存，大对象绕过 localStorage：临时状态优先存在内存对象里，仅当页面卸载前才持久化；超 100KB 的数据建议改用 IndexedDB。
容错与降级必须纳入测试范围
localStorage 不是永远可用的，测试不能只跑在理想环境：
- 手动触发 QuotaExceededError：往 localStorage 塞满数据后继续写入，验证是否捕获异常并降级到内存缓存；
- 禁用 localStorage 后测试 fallback 逻辑：可在 DevTools → Application → Storage 中勾选 “Disable localStorage”，看应用是否仍能维持基本功能；
- 模拟写入失败重试：故意让 navigator.sendBeacon 返回 false，检查 pending_* 键是否正确生成并在下次加载时自动重发。
