WebLocksAPI实现数据库写锁控制

Web Locks API 是浏览器原生提供的跨标签页资源协调机制，核心价值在于通过排他锁（exclusive lock）确保多个标签页对共享数据（如 IndexedDB）的读-改-写操作原子执行，从而彻底规避 ABA 覆盖和数据丢失——但关键陷阱在于：它只管“谁有资格写”，不自动等待数据库事务完成；必须将整个读取、计算、写入流程封装在 `navigator.locks.request()` 的回调中，并显式 `await tx.done`（或兼容老版本的 Promise 包装），否则锁提前释放将导致并发冲突；同时锁名需精准对应数据粒度（如 `user-123-profile`）、禁用随机化命名，并在 Safari 等不支持环境下果断降级为服务端幂等控制，而非用 localStorage 自欺欺人。

Web Locks API 本身不防止数据库写操作，它只协调“谁有资格执行写操作”。真正防冲突的关键是：把整个读-改-写流程包进 navigator.locks.request() 的回调里，并确保数据库事务（如 IndexedDB）的 tx.done 被 await —— 否则锁提前释放，别的标签页就插进来了。

为什么直接加锁 + indexedDB.put() 还会丢数据

很多人写成这样：

await navigator.locks.request('db-write', async () => {
  const tx = db.transaction('store', 'readwrite');
  tx.objectStore('store').put(data); // ❌ 没等事务结束就退出了
});

问题在于 put() 是异步发起但不返回 Promise，事务实际还在后台提交。锁在回调函数返回时就释放了，此时另一个标签页可能已拿到锁、读到旧值、覆盖写入。

必须显式等待事务完成：

• IndexedDB v3+ 支持 tx.done（Promise），务必 await tx.done
• 老版本需监听 tx.oncomplete 并用 Promise 包装
• 锁名必须固定且全局唯一，比如 'user-profile-write'，不能带时间戳或随机数

锁模式选 exclusive 还是 shared

写操作必须用 exclusive。即使你只想“读取后判断再写”，只要涉及修改，就必须排他——因为两个标签页同时读到相同旧值，各自计算后写入，就是典型的 ABA 覆盖问题。

shared 只适合纯读场景（比如多个标签页同步拉取配置），且需配合 exclusive 写锁使用（即读写锁分离）。但对单个写资源，别折腾，统一用 exclusive 更安全。

mode 不传默认是 exclusive，但建议显式写出，避免后续维护者误改。

浏览器兼容性与降级处理

navigator.locks 在 Safari 16.4+ 才支持，Chrome/Firefox/Edge 较新版本都 OK。私有窗口、跨源标签页之间锁完全隔离——这是同源策略决定的，不是 bug。

检测不支持时，不能简单跳过，否则多标签页立刻裸奔：

• 降级方案优先用 IndexedDB 自身事务（它能防同标签页内并发，但跨标签页无效）
• 更稳妥的是引入服务端幂等接口：前端生成唯一请求 ID，后端拒绝重复 ID 的写请求
• 切勿用 localStorage 模拟锁——它同步、无事务、无法被 navigator.locks 协调，只会掩盖问题

锁名设计和生命周期陷阱

锁名不是随便起的字符串。它本质是资源标识符，必须和你要保护的数据范围严格对齐。例如：

• 用户级操作 → 锁名用 `user-${userId}-profile`，而不是笼统的 'profile-write'
• 全局配置 → 锁名用 'app-config'，所有标签页共用一个锁
• 不要在锁名里拼接时间、随机数、DOM ID —— 这会让锁失去互斥意义

锁在回调函数返回（或抛错）后自动释放，无需手动清理。但要注意：如果回调里启动了未 await 的 Promise（比如漏了 await fetch()），锁会提前释放——这种 bug 很难复现，建议所有异步操作都显式 await 并加 try/catch。

到这里，我们也就讲完了《WebLocksAPI实现数据库写锁控制》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！