localStorage不支持分块读取，因它是同步字符串存储；大数据应迁至IndexedDB，结合Blob.slice、Stream API和Web Worker实现流式加载与解析。
不能直接用 localStorage 存储大容量 JSON 数据并“分块读取”——localStorage 本身不支持分块，它是键值对的同步字符串存储，没有流式或切片能力。真正可行的路径是：小数据留 localStorage 做轻量缓存，大数据必须迁移到 IndexedDB，并结合 Blob.slice + Stream API + Web Worker 实现分块加载与解析。
为什么 localStorage 不适合大 JSON 数据
localStorage 单条上限约 5–10MB（实际常低于 5MB），且所有操作同步阻塞主线程。存一个 2MB 的 JSON 字符串，会触发明显卡顿；反复读写更会导致跨标签排队等待。更重要的是，它只接受字符串，JSON.stringify/parse 过程中若含 Date、undefined、函数等类型，会静默丢失字段；超 100KB 就可能在低端设备上引发内存抖动或解析失败。
正确拆分策略：内存缓存 + IndexedDB 主存 + 按需流式加载
把“大 JSON 数据”理解为结构化集合（如用户历史记录列表、离线文章库、配置模板集），而非单个巨型对象：
Wjs Localizing Video
下载
用于端到端视频本地化流程的轻量编排器，路由至四个专注子技能——/wjs-transcribing-audio、/wjs-translating-subtitles...
- 用 localStorage 存轻量元信息：比如
lastSyncTime、dbVersion、hasIndexedDBInit，作为快速入口开关 - 真实数据全部写入 IndexedDB：按 objectStore 划分（如
articles、settings），支持索引查询、增量更新、事务回滚 - 首次加载时，从 IndexedDB 流式读取：调用
objectStore.openCursor()或cursor.advance(n)分页遍历，每次只处理几十条 - 对超长文本字段（如 article.content），可额外存为 Blob，读取时用
blob.slice(start, end)分段解码，避免整块 load 到内存
大文本类 JSON 的分块读取实现（如日志、导出数据）
若你面对的是一个几 MB 的纯文本 JSON 文件（例如用户导出的 JSON 日志包），需前端解析但不能全量加载，可走 File API + Stream 路径：
立即学习“前端免费学习笔记（深入）”；
- 用户选择文件后，获取
file对象，调用file.stream()创建 ReadableStream - 用
stream.getReader()获取 reader，循环reader.read()拿到{ value: Uint8Array, done: boolean } - 每块 Uint8Array 用
new TextDecoder().decode(chunk)转字符串，配合 JSON 解析器（如 stream-json）边流边 parse，跳过无效字段 - 关键：把该流程移入 Web Worker，主线程仅接收解析后的结构化结果（如每 100 条聚合一次），避免 UI 冻结
落地建议：避免踩坑的实操细节
不推荐手动拼接 JSON 字符串再分块存 localStorage——既不可靠也无性能收益。务必遵守以下底线：
- 写入前严格比对：用
JSON.stringify(newVal, Object.keys(newVal).sort()) === localStorage.getItem(key)防重复写 - 所有 localStorage 操作包裹 try/catch，捕获 QuotaExceededError 和 SecurityError，降级到 sessionStorage 或丢弃缓存
- 清理本地数据时，必须同步清空 localStorage、sessionStorage、IndexedDB 所有 database、以及 Service Worker 缓存，否则用户感知为“没清干净”
- 用
new Blob([jsonStr]).size预估体积，超过 64KB 就拒绝存 localStorage，强制走 IndexedDB
