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

「离线优先」应用上线后用户在地铁里断网都能打开草稿体验确实好。但我们有个不太敢说的细节一旦把整份离线态用户配置 草稿 缓存条目塞进localStorage切模块或自动保存那一刻页面会肉眼可见地顿一下。问题不在业务逻辑而在于——我们选了「最简单」的存储 API它恰恰在最不该阻塞的时候把主线程焊死了。背景为什么「最简单」的存储成了默认选项离线态的诉求很朴素断网可读、刷新不丢、最好零依赖。于是localStorage几乎成了肌肉记忆式的默认答案——API 只有getItem/setItem两个同步、字符串、写起来不费脑。但当离线态从「几个开关」长成「几 MB 的草稿与缓存」时这条默认路径就开始反噬同步读写会占用主线程数据越大卡得越久直接拖累 INPInteraction to Next Paint。本文不教你怎么用localStorage而是用一组实测数字回答一个问题离线态涨到多大这个「最简单」的 API 会从省事变成事故解剖localStorage 为什么必然阻塞主线程localStorage有三条底层约束决定了它和「主线程友好」天然对立同步 APIgetItem/setItem在主线程上执行浏览器要把数据落盘或至少做同步字符串往返才算返回期间 UI 渲染、点击、动画全部排队。只存字符串对象必须先JSON.stringify读出再JSON.parse两次序列化 CPU 开销与体积成正比。UTF-16 编码规范里 5MB 配额是按「字符」算的每个字符 2 字节真实 JSON 可用空间大约只有 ~250 万字符。也就是说一次「存离线态」在主线程上的真实占用 ≈stringify 耗时 同步写盘耗时 下次读时parse 耗时。这条链路没有任何一环能异步。图1setItem期间主线程被焊死渲染与输入事件全部排队数据越大冻结窗口越长。实证一次可复现的主线程占用测量我在 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–120msrizz.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 个矩阵门户https://github.com/wangzifan396-wzf/WB单文件工具聚合器https://github.com/wangzifan396-wzf/nano-workbenchGitHub 组织主页https://github.com/wangzifan396-wzf