Web Locks API 协调 Service Worker 并发写入

Web Locks API 并非用于协调“多个 Service Worker 实例”间的并发——因为同源下浏览器严格限制仅一个 Service Worker 处于 active 状态，所谓版本切换实为原子替换而非并行共存；它真正的价值在于解决跨执行上下文（如主线程、Web Worker、多 Tab）对同一 IndexedDB 资源的逻辑层竞态问题，通过细粒度命名锁（如 `idb:user:123`）确保读-改-写等易出错操作的串行化，但其有效性高度依赖锁名设计、事务边界控制及兼容性兜底策略，稍有不慎就会在 Safari 缺失支持、隐身模式隔离或锁范围遗漏副作用时导致数据不一致——掌握“锁什么”和“何时安全释放”，远比调用 `navigator.locks.request()` 本身更关键。

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 同步时，锁的范围必须覆盖全部副作用，否则一致性就断了。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。