indexeddb游标支持边遍历边修改，需复用readwrite事务、在onsuccess中调用put/delete/update，并立即continue；批量更新应建复合索引并分批处理，单次不超过500条以避免超时。
IndexedDB 游标本身不直接支持“边遍历边修改”，但结合事务与游标定位，可以安全高效地完成批量更新、条件改写、状态翻转等操作。关键在于避免 getAll() 加载全量数据，也不在游标遍历中频繁开启新事务——而是复用当前事务，在游标移动过程中调用 put() 或 delete()。
游标内修改数据的正确姿势
游标遍历期间，对象存储（objectStore）仍处于事务上下文中，此时可直接调用写操作方法。只要事务未提交或中止，所有变更都会被暂存并原子性提交。
- 必须使用 readwrite 事务：只读事务下无法调用
put()、delete() - 修改操作需在
onsuccess回调中、游标有效时执行（即cursor !== null） - 每次修改后建议立即调用
cursor.continue()，否则游标会停在当前项，导致漏遍历 - 不要在循环中重复调用
openCursor()—— 应复用同一个游标链路
批量更新指定条件的数据
比如将所有 status === 'pending' 的订单更新为 'processing'，且只处理最近 30 天内的记录：
- 先基于时间范围 + 状态字段建立复合索引：
store.createIndex('by_status_time', ['status', 'createdAt']) - 用该索引打开游标：
index.openCursor(IDBKeyRange.bound(['pending', Date.now() - 30*24*60*60*1000], ['pending', Infinity])) - 在游标回调中修改值并写回：
cursor.update({...cursor.value, status: 'processing'})（Dexie.js 支持）或手动store.put(updatedObj)
安全删除+重写替代（适合结构变更）
当字段结构需要调整（如把 email 拆成 emailLocal 和 emailDomain），不宜直接 mutate 原对象：
- 在游标中读取
cursor.value，构造新结构对象 - 调用
store.delete(cursor.primaryKey)删除旧记录 - 再用
store.put(newObj)写入新版数据 - 注意：主键若为自增数字，
primaryKey即为数字 ID；若为复合键，需保留原primaryKey或按业务逻辑生成新键
性能与稳定性要点
高频修改场景下，游标操作易触发事务超时或内存压力。几个硬性建议：
- 单次事务处理不超过 500 条 —— 可用
advance(500)分批，每批结束后手动commit并新开事务 - 避免在游标回调中做耗时同步计算（如正则匹配、JSON.parse）；复杂逻辑尽量前置或节流
- 始终监听
transaction.oncomplete和transaction.onerror，失败时需有回滚/重试机制 - 修改完成后记得检查游标是否自然结束（
cursor === null），而非靠计数判断
