核心问题是同步阻塞与高频调用叠加：每次setitem/getitem均需等待磁盘i/o完成，100次调用即100次主线程暂停，累积延迟可达上百毫秒；即便存储"true"等小额数据，仍经历完整序列化、写入、文件锁流程。

localStorage 在处理大量小额数据时，读写效率会快速下降，核心问题不在“数据小”，而在“次数多”和“同步阻塞”本身。

为什么小额数据也会变慢？

每次 setItem 或 getItem 都是同步操作，浏览器必须等磁盘 I/O 完成才能继续执行 JS。哪怕只存一个字符串如 "true"，背后仍涉及序列化、磁盘写入、文件锁等待等完整流程。100 次调用 = 100 次主线程暂停，累积延迟可能达数十甚至上百毫秒。

• 单次操作看似快（
• 键名本身也占空间（UTF-16 编码，每个字符 2 字节），1000 个键名就额外占用几 KB
• 浏览器内部对键值索引并非哈希表，键数量显著增多时，查找开销会上升

批量写入比逐条写入快得多

把 100 条小额数据合并成一个对象或数组再一次性存入，性能提升明显。因为只触发一次序列化 + 一次磁盘写入。

• 错误方式：for (let i = 0; i
• 推荐方式：const batch = Array.from({length: 100}, (_, i) => i); localStorage.setItem('batch', JSON.stringify(batch));
• 注意：JSON.stringify 对纯数字数组很快，但含嵌套对象时开销上升

读取时避免反复解析

如果经常读取其中某几个字段，不要每次都 JSON.parse(localStorage.getItem(...)) 整体反序列化——尤其当原始数据较大时。

• 可提前缓存解析结果到内存变量中，仅在数据变更时更新
• 若必须按需取字段，考虑改用 IndexedDB 并建轻量索引（例如只索引 id 和 status）
• localStorage 本身不支持部分读取，无法跳过无关字段解析

实际场景中的替代建议

小额但高频的数据（如用户操作日志、埋点缓存、临时表单状态），更适合用内存对象 + 节流持久化策略，而非直写 localStorage。

• 先写内存数组，每 5 秒或累计 50 条再批量刷入 localStorage
• 页面卸载前（beforeunload）做一次最终落盘，防止丢失
• 对一致性要求不高时，甚至可只保留在内存，关闭即丢弃