Web Locks API 仅提供同源单例资源的互斥执行控制，不负责权限同步；锁名须含业务唯一标识且URL-safe，mode必须显式设为'exclusive'，ifAvailable应启用以防阻塞，Safari不支持需服务端幂等兜底。
Web Locks API 确实能协调同源多标签页对单例资源的访问，但「同步权限」不是它的职责——它只保证「同一时间至多一个标签页执行某段逻辑」，不提供状态广播、权限授予或跨会话持久化能力。你要的不是“权限同步”，而是“互斥写入控制”。
锁名必须带业务唯一标识，否则所有标签页会抢同一把锁
很多人直接用固定字符串如 'cart' 或 'draft' 作锁名，结果用户 A 编辑自己的草稿时，用户 B 的草稿操作也被阻塞。这不是 bug，是设计使然：锁名就是作用域标识符，相同名字 = 全局互斥。
- 错：
navigator.locks.request('draft', cb)—— 所有 draft 都串行 - 对：
navigator.locks.request(`draft-${docId}`, cb)或`user-cart-${userId}` - 锁名需 URL-safe：避免空格、斜杠、控制字符；
encodeURIComponent()不必要，但可用来清理用户输入 - 长度无硬限制，但过长（如 >256 字符）可能影响内部哈希性能，建议控制在 64 字符内
navigator.locks.request() 的 mode 和 ifAvailable 必须显式设置
默认行为在旧版 Chrome 中静默 fallback 到 mode: 'shared'，而 shared 锁无法阻止并发写——这会导致你以为加了锁，实际毫无保护。
- 写操作必须用
mode: 'exclusive'，读操作才考虑shared - 不传
ifAvailable: true时，锁不可用会无限等待，UI 完全卡死；高交互场景务必启用： await navigator.locks.request(key, { mode: 'exclusive', ifAvailable: true }, cb)- 回调
cb必须返回 Promise，否则锁在函数退出后立即释放——别写return 'done'这种同步返回
Safari 完全不支持，fallback 不是可选项而是必选项
截至 iOS 17.5 / macOS 14.5，Safari 仍无 Web Locks API 支持痕迹。仅靠 if ('locks' in navigator) 跳过逻辑，等于在 Safari 里彻底放弃互斥保障。
- 服务端幂等是底线：每个写请求附带客户端生成的
requestId，后端校验是否已处理过 - 前端轻量 fallback 可用
localStorage+storage事件模拟：写前存lock:cart-123:timestamp，监听到冲突则提示“其他窗口正在编辑”，但注意这不是强一致，仅作友好提示 - 别在锁内做上传、加密、渲染等耗时操作——锁持有时间越长，排队越严重；只包「读-改-写」原子段，副作用（如通知、日志、UI 更新）移出锁外
真正容易被忽略的是锁的作用域边界：私有模式（隐身窗口）、不同源、跨设备，全部不共享锁。你以为的“全局互斥”，其实只在一个 origin + 一个用户代理 + 一个常规浏览会话内生效。超出这个范围，得靠服务端协调或最终一致性方案来兜底。
