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），而非靠计数判断