indexeddb 存储大文本需分片处理：按 utf-8 字节边界切分（如 ≤800kb/片），避免语义截断；用两个 objectstore 分离元数据与数据块，主键设为 [docid, index]；批量事务写入并校验边界、回滚错误；读取时流式解码，不全量加载。
IndexedDB 可以高效存储大文本数据，关键在于避免单条记录过大（如超过 10MB 容易触发浏览器限制或内存压力），需将文本按逻辑或字节切片、分块存入，并维护元信息实现可靠读取与拼接。
分片策略：按字符数或字节边界切分更稳妥
纯按字符切（如每 50 万字符一片）简单但可能截断 UTF-8 多字节字符；推荐按 UTF-8 字节长度切分（如每片 ≤ 800KB），并确保不打断多字节序列。可用 new TextEncoder().encode(str).length 获取真实字节数，切分时向后查找最近的合法 UTF-8 边界（如检查字节是否为 0xC0–0xF7 开头，再跳过后续 1–3 字节）。
- 避免在 HTML 标签中间、JSON 字段名/值边界、正则表达式边界等语义敏感处硬切
- 每片额外存一个
offset（原始文本起始字节位置）和isLast标志，便于顺序还原 - 示例：10MB 文本 → 切为约 13 片（按 800KB/片），每片含
id: "doc1_0", offset: 0, data: "...", isLast: false
数据库设计：用 objectStore 分离元数据与数据块
建两个 objectStore：docs_meta 存文档摘要（id、总大小、分片数、更新时间）；doc_chunks 存所有分片，主键设为复合键如 docId + index（用 IDBKeyRange 查询更高效）。索引建议加 docId 和 offset，支持按文档查全部分片或按偏移范围查。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
docs_meta主键用文档唯一标识（如 URL hash 或 UUID） -
doc_chunks主键可设为[docId, index]数组键，或拼接字符串"doc1_3" - 写入前先用
get()检查是否存在同 id 的 meta，避免重复缓存
写入优化：用 transaction + add() 批量插入，避免逐条阻塞
大文本分片后，不要循环调用 add() 单条写入——这会创建多个事务，开销大且易失败。应在一个 readwrite 事务中批量操作：
- 先
put()更新docs_meta - 再遍历分片数组，对每个 chunk 调用
objectStore.add(chunk) - 监听事务
oncomplete和onerror，失败时清理已写入分片（用delete()配合 keyRange） - 对超大文本（>50MB），考虑用
requestIdleCallback分批提交，防主线程卡顿
读取与拼接：流式还原，不全量加载到内存
读取时不必一次性 load 所有分片到内存拼接——尤其对百 MB 文本。可按需加载分片（如渲染编辑器视图时只拉当前可视区域对应 offset 的几片），或用 cursor 遍历 + TextDecoder 流式解码：
- 用
IDBIndex.openCursor(IDBKeyRange.bound([docId, 0], [docId, Infinity]))顺序读 chunk - 每读一片就
decoder.decode(chunk.data, {stream: true})追加到ReadableStream或Blob - 若需全文搜索，可另建
search_indexstore，存分片级关键词 + offset 映射，避免全量扫描
不复杂但容易忽略：切片边界校验、事务错误回滚、跨浏览器 IndexedDB 版本升级兼容（如新增 index 需在 onupgradeneeded 中处理）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
