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。
