如何用 Web Locks API 协调多个 Service Worker 实例对本地索引数据库的并发写入操作
开门见山，先说一个核心结论：Web Locks API 并不能用来协调多个 Service Worker 实例之间的锁。原因很简单：在同一源下，浏览器只允许一个 Service Worker 处于激活状态。所谓的“多个实例并发运行”，其实是一个常见的误解。
为什么不存在多个激活的 Service Worker 实例
要理解这一点，得从 Service Worker 的生命周期说起。它的状态流转是严格受控的：install → waiting → active。新版本安装后，旧版本虽然可能还在运行（比如服务于已打开的页面），但它已经进入了“退休”倒计时。一旦所有关联的客户端关闭或跳转，旧版本就会被终止，新版本随即上位成为唯一的 active 实例。
这意味着什么？意味着你永远无法在运行时同时拥有两个处于 active 状态的 Service Worker。所以，我们平时讨论的“多个实例”，实质上是不同版本在切换过程中的短暂共存，而非真正意义上的并行执行。
- 所谓“多个 Service Worker 实例”，实际是不同版本的切换过程，而非并行实例。
na vigator.locks在 Service Worker 中确实可用，但锁的作用域是“同源 + 同一锁管理器”。关键在于，这个锁管理器对于每个 Service Worker 的生命周期是独占的。- 即便你使用
skipWaiting()强制升级，也只是完成了一次替换，而不是在原有基础上叠加了一个新的运行实例。
真正需要锁协调的并发写入场景在哪
既然问题不在多个 Service Worker 之间，那么并发冲突究竟发生在哪里？答案通常藏在以下几个组合里：
主线程和激活的 Service Worker同时调用indexedDB.open()并执行写事务。Web Worker（注意，不是 Service Worker）与主线程或 Service Worker 共享同一个 IndexedDB 数据库。- 多个浏览器
标签页中的主线程，都试图写入同一个数据库，尤其是在使用versionchange事务进行数据库结构升级时。
在这些场景下，IndexedDB 自身的事务隔离机制（比如 readonly、readwrite、versionchange）提供了基础的保障。但是，它无法防止逻辑层的重复写入或竞态更新。举个典型的例子：“读-改-写”这个操作序列，如果没有锁的保护，就可能出现数据错乱。这时，才是 Web Locks API 真正该登场的时候。
如何用 na vigator.locks.request() 保护 IndexedDB 写操作
关键思路要转变：锁的目标不是“Service Worker”这个执行环境，而是具体的“资源”。通常，我们会用一个精心设计的锁名来标识资源，比如“数据库名 + 表名 + 主键”，从而确保对同一资源的操作是串行化的。
async function writeUserRecord(userId, data) {
// 锁粒度建议：按业务实体，而非整个数据库。过粗的锁会严重影响性能。
const lockName = `idb:user:${userId}`;
await na vigator.locks.request(lockName, { mode: 'exclusive' }, async (lock) => {
const db = await openDB(); // 这里假设是封装好的 indexedDB.open()
const tx = db.transaction('users', 'readwrite');
const store = tx.objectStore('users');
// 注意：所有写操作必须在锁的持有期间内完成
await store.put({ id: userId, ...data });
await tx.done; // 等待事务提交完成，这是关键一步
});
}
- 锁名设计：必须唯一且稳定。避免使用时间戳或随机数动态拼接，否则每次请求的锁名都不同，锁就失去了意义。
- 锁内操作：不要在锁的回调函数内部再进行跨上下文的通信（比如向主线程
postMessage），这会导致锁的释放时机变得不可预测。 - 事务完成：代码中的
tx.done是一种 Promise 化的封装（也可以用new Promise(r => tx.oncomplete = r)替代），它的作用是确保数据真正写入磁盘后再释放锁。 - 执行环境：在 Service Worker 中调用时，务必确认其已处于
active状态，否则na vigator.locks可能尚未就绪。
容易被忽略的兼容性与边界问题
技术选型不能只看理想情况，Web Locks API 在部分环境下的表现需要特别注意：
- Firefox：直到 v125 版本才完整支持
mode: 'upgrade'模式。此外，在 Service Worker 脚本中，query()方法目前并不可用。 - Safari：截至 2026 年 4 月，Safari 仍然不支持 Web Locks API。这意味着必须设计降级方案，例如使用
localStorage做标记配合轮询，或者干脆依赖 IndexedDB 事务的重试机制。 - 锁的作用域：锁无法跨浏览器进程。隐身窗口、不同的用户配置文件、甚至是不同的浏览器，都会被视作独立的锁域。
- 超时与阻塞：锁的默认持有时间为无限长，但长时间阻塞操作可能触发浏览器的干预机制，在 Service Worker 这种后台环境中尤其需要注意。
话说回来，真正棘手的问题从来不是“怎么加锁”，而是“锁什么”以及“什么时候释放最安全”。特别是当一次写操作不仅涉及数据库，还可能触发缓存更新（caches.put）、推送通知，甚至需要同步到其他标签页时，锁的范围必须覆盖所有这些副作用。否则，数据的一致性链条就可能断裂，留下难以排查的隐患。
