indexeddb读取时的数据转换应避免在游标遍历中实时处理，而应在写入端预标准化、索引层精准过滤或视图层按需解构，以减少内存占用与性能损耗。
IndexedDB 读取时的数据转换逻辑，往往被当成“取出来再处理”的简单步骤，但实际中它常成为性能瓶颈和内存压力源——尤其在批量读取、字段映射频繁、或需兼容旧数据结构的场景下。优化重点不在“怎么转”，而在于“什么时候转、转多少、是否必须转”。
避免在游标遍历中实时转换
很多开发者习惯在 cursor.onsuccess 里对每条 record 做格式标准化（如时间戳转 Date 对象、布尔值归一化、字段重命名）。这会导致：重复解析开销、阻塞事务生命周期、难以中断或分片处理。
- 把转换逻辑后移到应用层，仅在真正需要时才执行（比如渲染前、导出前）
- 若必须预处理，改用 IDBKeyRange + getAll() 批量读取后统一转换，减少事件循环调度次数
- 对高频访问字段（如 timestamp、read），可在写入时就存为标准格式，读取即用
利用索引键值直接过滤，减少无效数据加载
读取阶段的“转换”常源于查询条件不精准——比如想查“今天未读消息”，却 getAll() 后用 JS 过滤 date 和 read 字段。这会把大量无关数据从磁盘载入内存，再丢弃。
- 为常用组合条件建复合索引，例如 createIndex('by_user_read_time', ['userId', 'read', 'timestamp'], { unique: false })
- 用 IDBKeyRange.bound 构造精确范围，让 IndexedDB 在底层完成筛选，只返回目标数据
- 避免 getAll().then(arr => arr.filter(...)) 这类全量拉取+JS 过滤模式
按需解构，分离原始数据与视图模型
前端组件并不总需要完整 record 对象。比如列表页只需 id、content、timestamp、read；详情页才需要全部字段及关联 blob。
- 定义轻量级投影接口（如 getSummary()），只读取必要字段：objectStore.index('summary').getAllKeys() 或配合 openCursor(IDBKeyRange.only(key))
- 对大字段（如 content 是长文本、blob 是图片）做延迟加载：record 中只存元数据，点击/滚动到可视区再 fetch 实际内容
- 使用结构化克隆替代 JSON.parse(JSON.stringify()) 做深拷贝转换，更高效且支持 Map/Set/Blob 等原生类型
版本迁移时统一清洗，而非运行时兜底
老版本数据结构混乱（如 timestamp 有时是字符串、有时是毫秒数、有时缺字段）是转换逻辑膨胀的主因。每次读取都加 if-else 兜底，既难维护又拖慢速度。
- 在 onupgradeneeded 中对旧 store 执行一次性迁移：用游标遍历旧数据，写入新格式到临时 store，再原子替换
- 新写入强制校验 Schema（可用 Zod 或简单 type guard），从源头杜绝脏数据
- 保留原始字段（如 _rawTimestamp）供调试，业务层只操作标准化字段（timestamp）
数据转换不是越早越好，而是越贴近使用点越合理。把逻辑沉到写入端、索引层或视图层，比堆在读取回调里更可控、更可测、也更省资源。
