localStorage仅支持字符串存储，故对象、数组等复杂类型必须经JSON.stringify()序列化后才能存入，否则将变为"[object Object]"等不可还原字符串；该操作在数据量大或高频读写时会引发显著CPU开销与主线程阻塞。
localStorage 本身只支持字符串，存对象、数组这类复杂类型必须先转成字符串——最常用也最直接的方式就是 JSON 序列化。但这看似简单的一步，在真实业务里常成为性能瓶颈，尤其数据量稍大或读写频繁时。
为什么必须序列化？
localStorage 的 API（setItem / getItem）只接受字符串作为 value。哪怕你传一个数字、布尔值甚至 null，它都会被自动 toString()；而对象、数组、Date、RegExp 等类型如果不处理，存进去就是 [object Object] 或 undefined，读出来完全无法还原。
- JSON.stringify() 是目前最通用、兼容性最好的序列化方式
- 它能正确处理 plain object、array、string、number、boolean、null
- 但对 Date、Map、Set、Function、undefined、循环引用等原生不支持，需额外处理
JSON 序列化的实际开销有多大？
不是“小到可以忽略”。实测显示：存取一个含 1 万个字符串元素的数组，JSON.stringify() + localStorage.setItem() 组合在中低端手机上可能耗时 40–70ms，足够造成肉眼可感的卡顿。
- 序列化是 CPU 密集型操作，主线程阻塞，页面交互会暂停
- 反序列化（JSON.parse）同样耗时，尤其在首次加载或频繁读取场景
- localStorage 本身也是同步 I/O，浏览器要等磁盘写入完成才返回，叠加序列化更慢
哪些场景容易踩坑？
不是所有对象都适合直接 JSON 存 localStorage。以下几类要特别注意：
- 含 Date 实例的对象：JSON.stringify 会转成 ISO 字符串，读取后仍是字符串，不是 Date 对象，需手动 new Date()
- 带方法或原型链的数据：函数、class 实例方法、Symbol 属性全丢失，只剩可枚举自有属性
- 大体积缓存（如离线文章、图表数据）：单条超 1MB 就明显拖慢，且接近 5–10MB 上限时，部分浏览器会静默失败或清空旧数据
- 高频更新状态（如实时协作光标、倒计时）：每秒多次 setItem 会持续阻塞主线程，UI 响应变迟钝
有没有更优的替代思路？
不是非要“不用 JSON”，而是根据场景选更合适的组合：
- 小而稳的配置类数据（用户主题、语言、表单草稿）：用 JSON 完全合适，代码简洁、调试方便
- 中等规模结构化数据（购物车、历史记录）：可加内存缓存层，只在离开页面或显式保存时同步到 localStorage
- 大数据或高频率场景：换 IndexedDB（异步、容量大、支持二进制），或用 localForage 封装，自动降级兼容
-
需要保留特殊类型（Date/Map/Set）：可封装自定义序列化器，比如用
structuredClone（现代浏览器支持）替代 JSON，或引入 msgpack 等二进制格式（体积更小、解析更快）
本质上，localStorage 不是数据库，它是个轻量键值存储。把 JSON 当作“默认选项”没问题，但得清楚它的代价在哪里。真正影响体验的，往往不是“能不能存”，而是“要不要每次都存、存多大、存什么”。
