如何借助Web Locks API防止多个浏览器标签页同时向同一数据库发起写操作

Web Locks API 仅协调写操作资格，不直接防止数据库冲突；必须将完整读-改-写流程包入 navigator.locks.request() 回调，并 await tx.done 确保事务完成后再释放锁，否则会导致ABA覆盖和数据丢失。

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。