如何借助 Web Locks API 协调多个 Service Worker 实例对本地索引数据库的并发写入操作

Web Locks API 不能协调多个 Service Worker 实例间的锁，因同源下浏览器只允许一个 Service Worker 处于 active 状态；其生命周期为 install→waiting→active，新旧版本不共存执行，所谓“多个实例”实为版本切换而非并发。

Web Locks API 不能协调多个 Service Worker 实例之间的锁 —— 因为同一源下，浏览器**只允许一个 Service Worker 处于激活状态**，不存在“多个实例”并发运行的场景。

为什么不存在多个激活的 Service Worker 实例

Service Worker 的生命周期由浏览器严格控制：install → waiting → active。新版本安装完成后，旧版仍可运行（比如已有 clients），但一旦所有 clients 关闭或跳转，旧版即被终止；新版进入 active 状态后，**旧版不会与新版共存执行**。因此你永远无法在运行时同时拥有两个处于 active 状态的 Service Worker。

• 所谓“多个 Service Worker 实例”，实际是不同版本的切换过程，而非并行实例
• navigator.locks 在 Service Worker 中可用，但锁的作用域是“同源 + 同一锁管理器”，而该管理器对每个 Service Worker 生命周期是独占的
• 即使你用 skipWaiting() 强制升级，也只是替换，不是叠加

真正需要锁协调的并发写入场景在哪

并发冲突通常发生在以下组合中，而非“多个 SW”之间：

• 主线程 和 active Service Worker 同时调用 indexedDB.open() 并执行写事务
• Web Worker（非 Service Worker）与主线程/Service Worker 共享同一 IndexedDB 数据库
• 多个浏览器 Tab 中的主线程，都试图写入同一个数据库（尤其使用 versionchange 事务时）

这些场景下，IndexedDB 自身的事务隔离（如 readonly / readwrite / versionchange）已提供基础保障，但**无法防止逻辑层重复写入或竞态更新**（例如：读-改-写未加锁）。这时才需要 Web Locks API 插手。

如何用 navigator.locks.request() 保护 IndexedDB 写操作

关键不是锁“Service Worker”，而是锁“资源名”，比如数据库名 + 表名 + 主键，确保逻辑串行化：

async function writeUserRecord(userId, data) {  // 锁粒度建议：按业务实体，而非整个 DB  const lockName = `idb:user:${userId}`;    await navigator.locks.request(lockName, { mode: 'exclusive' }, async (lock) => {    const db = await openDB(); // 封装好的 indexedDB.open()    const tx = db.transaction('users', 'readwrite');    const store = tx.objectStore('users');        // 注意：必须在 lock 持有期间完成全部写操作    await store.put({ id: userId, ...data });    await tx.done; // 等待事务提交完成  });}

• 锁名必须唯一且稳定，避免用动态拼接导致不一致（如时间戳、随机数）
• 不要在 lock 回调里再发起跨上下文通信（如 postMessage 到主线程），否则锁释放时机不可控
• tx.done 是 Promise 化封装（可用 new Promise(r => tx.oncomplete = r) 替代），确保事务真正落地后再退出回调
• Service Worker 中调用时，需确认其处于 active 状态（否则 navigator.locks 可能未就绪）

容易被忽略的兼容性与边界问题

Web Locks API 在部分环境表现受限：

• Firefox 直到 v125 才完整支持 mode: 'upgrade'，且不支持在 service-worker.js 中使用 query()
• Safari 仍不支持 Web Locks API（截至 2026 年 4 月）—— 必须降级 fallback，例如用 localStorage 标记 + 轮询，或直接依赖 IndexedDB 事务重试
• 锁不会跨浏览器进程：隐身窗口、多用户配置文件、不同浏览器均视为独立锁域
• 锁持有超时默认为 Infinity，但长时间阻塞可能触发浏览器干预（尤其在 Service Worker 中）

真正棘手的从来不是“怎么加锁”，而是“锁什么”和“什么时候释放最安全”——尤其是当写操作涉及缓存更新（caches.put）、推送通知、甚至跨 Tab 同步时，锁的范围必须覆盖全部副作用，否则一致性就断了。