Web Locks API需与IndexedDB配合实现跨标签页串行化：锁控制执行权，IndexedDB事务保证原子性；localStorage因同步阻塞无法与锁协同，必须弃用；锁名须业务粒度唯一且URL-safe，回调内仅含读-改-写最小闭环，并await tx.done确保持久化。

Web Locks API 本身不解决冲突，它只提供跨标签页的互斥协调能力。真正起作用的是你如何用它包裹“读取 → 修改 → 写入”这一整段有状态变更的逻辑，并搭配支持事务与异步完成确认的底层存储。

必须放弃 localStorage

localStorage 是同步阻塞式 API，setItem 瞬间落盘，Web Locks 的 Promise 根本插不进执行流。加锁后多个标签页仍会毫秒级内先后写入，覆盖无法避免。这不是锁没起作用，而是锁对同步操作完全无干预能力。

• 别再尝试 navigator.locks.request('cart', () => localStorage.setItem(...)) —— 这类写法无效且掩盖问题
• 所有涉及多标签页协同更新本地数据的场景（如用户偏好、草稿、计数器），都应迁移到 IndexedDB
• 若仅需简单键值存取且无并发要求，localStorage 可保留；但一旦出现“读旧值→算新值→写回”模式，就必须换方案

首选组合：IndexedDB + Web Locks

这是目前最轻量、纯前端、可落地的现代方案。Web Locks 控制谁有资格执行，IndexedDB 事务保证单次操作原子性，两者配合才能实现跨标签页串行化。

• 锁名必须带业务粒度标识，例如 user-theme-write、note-789-edit、cart-item-456，不能是泛化名如 'db-write'
• 整个流程必须包裹在 await navigator.locks.request() 回调中：打开 DB → 启动 readwrite 事务 → get() 读旧值 → 计算新值 → put() → await tx.done
• tx.done 是关键：它代表事务真正持久化完成；仅调用 put() 或 commit() 不足以防止锁提前释放导致的 ABA 覆盖

服务端兜底是硬性要求

Web Locks 仅限同源标签页，不跨设备、不跨浏览器、不覆盖 Safari 旧版本。任何生产环境都不能依赖它作为唯一防线。

• 所有写请求必须携带客户端生成的唯一 requestId，后端据此做幂等校验或拒绝重复提交
• 对强一致性要求高的操作（如转账、库存扣减），建议后端配合 ETag 或 _rev 字段做乐观并发控制
• 前端可结合 storage 事件监听，在 Safari 或锁不可用时弹出提示：“其他窗口正在编辑”，而非静默覆盖

锁设计与执行细节决定成败

很多团队加了锁却仍有冲突，问题往往出在锁生命周期管理上，而非 API 调用本身。

• 必须 await navigator.locks.request()：不 await 就等于没锁，Promise 被丢弃，锁立即释放
• 锁回调内只放最小闭环逻辑：读-改-写，耗时操作（加密、渲染、大数组处理）一律移出锁外
• mode 必须显式设为 'exclusive'；shared 模式只适用于纯读场景，且需与写锁协同设计，易引入死锁
• 锁名需 URL-safe，避免空格、斜杠；长度建议 ≤64 字符；不能含时间戳或随机数，否则失去互斥意义