如何利用 Web Locks API 在离线应用中实现多标签页对 IndexedDB 的事务性写保护
在构建离线优先的Web应用时，IndexedDB是客户端存储的基石。然而，一个常见的痛点也随之浮现：当用户在多个浏览器标签页中同时操作同一份数据时，如何避免静默的数据覆盖？
Web Locks API 本身并不直接参与 IndexedDB 的事务控制，但它恰恰是解决多标签页并发写入竞态问题的关键。它与 IndexedDB 的事务机制形成了完美的互补：后者保障单次事务内操作的原子性与一致性；而前者则确保了多个上下文（如标签页、Worker）对同一逻辑资源的互斥访问。简单来说，IndexedDB管“内部”，Web Locks管“外部”。
为什么需要 Web Locks 配合 IndexedDB？
问题的根源在于，IndexedDB的事务是“会话级”的。每个标签页打开的数据库连接相互独立，互不知晓。想象一下，用户在标签页A中编辑笔记A，同时在标签页B中也打开了同一篇笔记A进行修改。即便两个标签页都使用了readwrite事务，它们之间也缺乏协调机制，最终的结果往往是“后保存者获胜”，先前的修改被悄无声息地覆盖。这种数据丢失是用户和开发者都不愿看到的。而Web Locks API，正是为此设计的轻量级协调原语。
典型场景：离线笔记应用的双标签冲突预防
让我们用一个具体场景来拆解。假设一篇笔记的ID是note_123，用户在两个标签页中同时打开了它：
- 标签页A：首先获取名为
lock:note_123的独占锁。成功后，它便安心地读取旧数据、修改、写入IndexedDB，最后释放锁。 - 标签页B：几乎同时尝试获取同名的
lock:note_123。此时，根据请求模式（mode）的不同，它要么被阻塞等待，要么立即失败。应用可以借此机会友好地提示用户：“该笔记正在其他窗口中编辑”，或者让操作排队等待。
看，通过这样一把逻辑上的“锁”，就从源头上杜绝了“最后写入覆盖”这类静默错误，用户体验和数据一致性都得到了保障。
实际集成步骤（带错误防护）
将Web Locks与IndexedDB结合使用，需要一套清晰的流程。以下是带错误防护的核心步骤：
- 首先，调用
na vigator.locks.request('lock:note_123', { mode: 'exclusive' }, async lock => { ... })来请求独占锁。 - 在锁的回调函数内部，再打开IndexedDB数据库，并启动一个
readwrite事务。 - 这是一个关键细节：在事务中，先用
objectStore.get(id)读取数据的当前版本。务必校验updatedAt时间戳或version等版本字段。这相当于在应用层增加了一道乐观锁，防止在获取锁之后、写入之前，数据已被其他途径（如同步进程）更新。 - 校验通过后，执行
put()更新操作，并妥善处理事务的oncomplete和onerror事件。 - 无论事务成功还是失败，都要确保锁的逻辑边界清晰。虽然锁在回调函数结束时会自动释放，但显式地处理异常和释放逻辑能让代码更健壮。
注意事项与常见陷阱
当然，Web Locks API并非万能钥匙，使用时有几个重要的边界和陷阱需要留意：
- 锁的命名：锁名必须是字符串。最佳实践是根据业务实体维度来命名，例如
lock:user_456、lock:cart。避免使用全局锁，否则会严重影响应用的并发性能。 - 作用域：锁的作用域默认是同源（origin）级别。这意味着同一个域名下的所有标签页、iframe和Service Worker共享锁状态，但它无法跨域协作。
- 持久性：Web Locks是内存态的，页面关闭或浏览器异常退出后，锁会自动释放，无需开发者手动清理残留锁。
- 功能限制：它不支持锁的嵌套，也不直接提供超时后自动释放的机制（但可以通过
AbortSignal来实现类似控制）。 - 兼容性：需要特别注意，部分旧版本的Safari浏览器（iOS和macOS 14及以下）不支持Web Locks API。在面向这些环境时，务必设计降级方案，例如回退到仅使用IndexedDB的乐观版本校验，并辅以明确的用户提示。
总而言之，Web Locks API并不替代IndexedDB事务，它的角色是让这些事务能够在一个更安全、更有序的上下文中执行。对于任何涉及多标签页数据操作的离线Web应用来说，理解并运用这套组合拳，无疑是提升应用健壮性的关键一步。
