localStorage 是同步阻塞的，每次 getItem 或 setItem 都会暂停 JavaScript 主线程等待磁盘 I/O，导致 UI 卡顿、交互无响应、动画掉帧；高频读写或大数据量时问题加剧，单次操作可达 20–50ms，远超 16ms 渲染帧预算。
localStorage 是同步阻塞的，这意味着每次 getItem 或 setItem 调用都会让 JavaScript 主线程停下来，等硬盘操作完成才继续。UI 渲染、用户交互、动画帧（如 requestAnimationFrame）全跑在同一线程上，一旦被 localStorage 拖住，页面就“卡死”——不是假死，是真停摆。
看代码就能感知阻塞：一次调用 = 一次主线程暂停
下面这段代码看似简单，但执行时 UI 会明显卡顿：
console.time('write');<br>localStorage.setItem('data', JSON.stringify(largeArray));<br>console.timeEnd('write'); // 可能耗时 40ms+
这 40ms 内，浏览器无法响应点击、滚动、输入，setTimeout 回调不会触发，requestAnimationFrame 帧也会跳过。因为 JS 引擎正等着磁盘写完，什么也干不了。
高频读写放大阻塞效应：小操作积少成多
单次读写可能只卡几毫秒，但高频场景下问题立刻凸显：
- 自动保存表单草稿：每输入 100ms 就存一次，主线程持续被打断
- 实时状态同步：多个组件轮询读取同一 key，反复触发磁盘读取
- 循环批量写入：for 循环中逐条
setItem，相当于连续阻塞 N 次
尤其当值是大型数组或嵌套对象时，JSON.stringify 和 JSON.parse 的 CPU 开销叠加磁盘 I/O，单次操作轻松突破 20–50ms，远超 16ms 的渲染帧预算。
用 Performance API 实测阻塞时长
不用猜，直接测。在关键路径插入性能标记：
const start = performance.now();<br>const value = localStorage.getItem('config');<br>const end = performance.now();<br>if (end - start > 2) {<br> console.warn(`localStorage.getItem took ${end - start}ms — likely blocking UI`);<br>}
Chrome DevTools 的 **Performance 面板**也能直观看到：在录制过程中，若出现长任务（Long Task），点开后常能看到 localStorage.getItem 或 setItem 占据大部分执行时间，且下方无其他 JS 执行痕迹——这就是典型同步阻塞证据。
和真正异步方案对比：一眼看出差异
IndexedDB 同样存数据到磁盘，但它是异步的：
// localStorage：同步，卡主线程<br>localStorage.setItem('key', 'value');<br>console.log('这行要等写完才执行');
// IndexedDB：不阻塞，后续代码立刻运行<br>db.transaction('store').objectStore('store').put('value', 'key');<br>console.log('这行马上执行，不管写没写完');
前者像在银行柜台排队办业务，你得站那儿等；后者像填完单子交给柜员，转身就能去喝咖啡——前端体验天壤之别。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
