web worker 中使用 indexeddb 实现事务型离线计算，可避免主线程阻塞、支持并行任务、保障数据原子性与自动回滚；数据库升级须在主线程进行，worker 仅连接现有版本，需注意事务生命周期与跨 worker 数据传递限制。
在 web worker 中使用 indexeddb 进行事务型离线本地计算，是构建高性能、不卡顿离线应用的关键实践。主线程负责 ui 渲染与用户交互，而耗时的数据处理（如批量解析 json、统计笔记修改次数、生成离线报表）应交给 web worker；再配合 indexeddb 的事务能力，就能实现可靠、可回滚、多步骤联动的本地计算逻辑。
为什么必须在 Worker 里操作 IndexedDB？
IndexedDB 虽然是异步 API，但其 open、transaction 等操作仍会触发微任务调度和内部资源竞争，在高频率或大数据量场景下可能轻微拖慢主线程响应。更重要的是，某些浏览器（如 Safari）对主线程中频繁 IndexedDB 操作有隐式节流。而在 Web Worker 中：
- 完全脱离 UI 渲染循环，无阻塞风险
- 可并行执行多个独立数据任务（例如：一个 Worker 处理日志聚合，另一个同步用户草稿）
- 页面意外刷新或关闭时，Worker 中未完成的事务会被自动终止，避免脏写——这反而是种安全机制
事务型本地计算的核心结构
所谓“事务型”，不是指单次 put，而是将一组强关联的读—算—写操作封装在一个 readwrite 事务中，确保原子性。典型模式如下：
- 读取原始数据：用游标或索引查询一批待处理记录（如 status = 'pending' 的同步任务）
- 本地计算逻辑：在 Worker 线程内执行纯 JS 计算（无需 await，不触发网络）
- 批量写入结果：在同一个事务中更新原记录 + 插入新衍生数据 + 修改状态标记
- 异常自动回滚：任意一步出错（如计算溢出、键冲突），整个事务静默失败，数据保持原状
示例：离线笔记应用中，批量导出选中笔记为 Markdown 并生成摘要，同时标记为“已导出”：
// dataProcessor.js（Web Worker 内）const db = await openDB('NoteDB', 2);
const tx = db.transaction(['notes', 'exports'], 'readwrite');
const notesStore = tx.objectStore('notes');
const exportsStore = tx.objectStore('exports');
const pendingReq = notesStore.index('status').getAll(IDBKeyRange.only('pending'));
const pendingNotes = await pendingReq;
for (const note of pendingNotes) {
const md = convertToMarkdown(note.content);
const summary = generateSummary(md);
exportsStore.put({ id: `${note.id}_export`, noteId: note.id, md, summary, ts: Date.now() });
notesStore.put({ ...note, status: 'exported' }); // 同一事务内更新
}
关键细节与避坑点
Worker + IndexedDB 组合看似简单，但几个细节决定成败：
- 数据库版本升级必须在主线程触发：onupgradeneeded 只在主线程 open 时执行。Worker 中只能连接已存在的数据库版本，不能新建或升级 store
- 事务生命周期由 Worker 控制：不要在事务未完成前让 Worker 退出（比如直接 return 或 postMessage 后没等 oncomplete）。建议用 Promise 封装整个流程
- 避免跨 Worker 共享 DB 实例：每个 Worker 应独立调用 indexedDB.open，浏览器会自动复用底层连接，但实例不可共享引用
- 大对象注意 Blob/ArrayBuffer 传递限制：Worker 间传 Blob 需 transfer，但 IndexedDB 存储本身支持原生 Blob，无需额外序列化
与 Service Worker 协同构建完整离线闭环
Web Worker 负责“算”，Service Worker 负责“取”和“发”。典型协同流程：
- Service Worker 拦截 /api/sync 请求 → 发现离线 → 将请求体存入 IndexedDB 的 pending_queue 表
- 主线程通知 Web Worker：“有新同步任务” → Worker 从 pending_queue 读取、脱敏、压缩、加密 → 写入 encrypted_payload 表
- 网络恢复后，Service Worker 监听 background sync 事件 → 从 encrypted_payload 读取并发起真实请求 → 成功后通知 Worker 清理记录
这种分工让离线计算真正“可预测、可验证、可审计”，而不是把所有逻辑堆在 fetch 事件里硬扛。
