当前位置：首页 > news >正文

离线态刚过 1MB，主线程就被 localStorage 卡了 6.7ms：一次关于「最简单存储」的实测复盘

news 2026/8/3 4:42:18

「离线优先」应用上线后，用户在地铁里断网都能打开草稿，体验确实好。但我们有个不太敢说的细节：一旦把整份离线态（用户配置 + 草稿 + 缓存条目）塞进localStorage，切模块或自动保存那一刻，页面会肉眼可见地顿一下。问题不在业务逻辑，而在于——我们选了「最简单」的存储 API，它恰恰在最不该阻塞的时候，把主线程焊死了。

背景：为什么「最简单」的存储成了默认选项

离线态的诉求很朴素：断网可读、刷新不丢、最好零依赖。于是localStorage几乎成了肌肉记忆式的默认答案——API 只有getItem/setItem两个，同步、字符串、写起来不费脑。

但当离线态从「几个开关」长成「几 MB 的草稿与缓存」时，这条默认路径就开始反噬：同步读写会占用主线程，数据越大卡得越久，直接拖累 INP（Interaction to Next Paint）。本文不教你怎么用localStorage，而是用一组实测数字回答一个问题：离线态涨到多大，这个「最简单」的 API 会从省事变成事故？

解剖：localStorage 为什么必然阻塞主线程

localStorage有三条底层约束，决定了它和「主线程友好」天然对立：

同步 API：getItem/setItem在主线程上执行，浏览器要把数据落盘（或至少做同步字符串往返）才算返回，期间 UI 渲染、点击、动画全部排队。
只存字符串：对象必须先JSON.stringify，读出再JSON.parse，两次序列化 CPU 开销与体积成正比。
UTF-16 编码：规范里 5MB 配额是按「字符」算的，每个字符 2 字节，真实 JSON 可用空间大约只有 ~250 万字符。

也就是说，一次「存离线态」在主线程上的真实占用 ≈stringify 耗时 + 同步写盘耗时 +（下次读时）parse 耗时。这条链路没有任何一环能异步。

图1：setItem期间主线程被焊死，渲染与输入事件全部排队；数据越大，冻结窗口越长。

实证：一次可复现的主线程占用测量

我在 Node 22 上构造贴近真实离线态的嵌套对象（用户配置 + 数千条草稿条目），对「存一次」的三个阶段分别取 7 轮中位数：

node bench_offline_storage.cjs # size_KB | strChars | stringify_ms | write_ms | parse_ms | total_ms | longTask(>50ms) # 50 | 69325 | 0.15 | 0.47 | 0.15 | 0.77 | no # 200 | 278242 | 0.60 | 0.50 | 0.60 | 1.70 | no # 500 | 699874 | 1.42 | 0.72 | 1.69 | 3.83 | no # 1000 | 1402594 | 2.87 | 1.17 | 2.65 | 6.69 | no # 2000 | 2812087 | 5.57 | 1.78 | 5.40 | 12.75 | no # 4000 | 5653687 | 10.55 | 3.17 | 10.97 | 24.69 | no

图2：总占用随体积近似线性上升。桌面 Node 只是「下限」——浏览器还有 UTF-16 编码与磁盘 I/O，中端安卓实测 2MB 读取可达 80–120ms（rizz.dev 生产测量），早已越过 50ms Long Task 红线。

结论很直接：上面的数字是在桌面 Node 上测的，是真实浏览器阻塞的「地板」而非「天花板」。真正的风险在移动端——同样的 1MB 离线态，在中端安卓上主线程占用是桌面 5–20 倍，轻松越过 Google 定义的 50ms Long Task 预算，INP 直接被拖垮。所谓「最简单」，只是把阻塞成本从你写代码时，平移到了用户滑动屏幕时。

解剖：IndexedDB 是怎么把工作挪出主线程的

IndexedDB 同样是浏览器内置、零依赖，但它是异步 + 事务 + 结构化克隆——Uint8Array、嵌套对象、Map/Set都能原生存，且写调用立刻返回，真正的落盘在后台事务里完成。

// 一个最小 Promise 封装，替换 localStorage 的同步调用 function openDB() { return new Promise((res, rej) => { const r = indexedDB.open('offline-state', 1); r.onupgradeneeded = e => e.target.result.createObjectStore('kv'); r.onsuccess = e => res(e.target.result); r.onerror = e => rej(e.target.error); }); } export async function saveState(key, value) { const db = await openDB(); await new Promise((res, rej) => { const tx = db.transaction('kv', 'readwrite'); tx.objectStore('kv').put(value, key); // 立刻返回，落盘在后台事务 tx.oncomplete = res; tx.onerror = e => rej(e.error); }); } // 用法：await saveState('draft', bigObj) // 不再阻塞主线程

图3：同样的「存一次」，IndexedDB 在put处立即把控制权交还主线程，磁盘写入在事务里发生，UI 始终可响应。

局限：换库不是免死金牌

实测复盘必须讲边界，否则就是另一篇「一踩一捧」：

反序列化仍在主线程：IndexedDB 回调用里getAll拿回大对象后，你的业务逻辑解析它依然占主线程；大对象要分块或懒加载，别一次性getAll。
API 更啰嗦：对比localStorage两行，原生 IndexedDB 要写 open/upgrade/transaction，建议用idb-keyval这类薄封装拿到「类 localStorage 手感」。
小数据别过度设计：存一个theme: 'dark'也上 IndexedDB，是拿数据库记开关。分层策略才是正解——小偏好留localStorage/sessionStorage，大/结构化/二进制走 IndexedDB，敏感凭证走 HttpOnly Cookie。

一句话方法论：按「数据大小 + 生命周期」选存储，而不是按「哪个 API 最熟」选。离线态过几百 KB，就该从同步存储毕业了。

结论与下一步

「最简单」的localStorage在离线态过 1MB 量级就会把主线程占用推到桌面 6.7ms、移动端越过 50ms Long Task 红线的程度——它省的是你写代码的时间，透支的是用户滑动屏幕的流畅度。可复现的结论是：用 Node 测出stringify + 写盘 + parse随体积近似线性增长，再叠加浏览器 UTF-16 与磁盘 I/O，真实阻塞只会更高；把大离线态迁到异步 IndexedDB，并把存储按「大小 + 生命周期」分层，INP 才能稳。

开源地址（结论段，指向同一组织即可，3 个）：