navigator.locks 仅保证同源多标签页对单例资源的排他执行，需显式指定 mode: 'exclusive'、唯一锁名及 ifAvailable: true，且 Safari 不支持，服务端幂等才是兜底。
直接说结论：navigator.locks 能协调同源多标签页对单例资源的独占访问，但「权限」不是它分发的，它只保证「同一时间至多一个标签页执行某段逻辑」——你得自己把读-改-写包进去，且锁名、mode、ifAvailable 三者缺一不可。
为什么 mode: 'exclusive' 必须显式写，不能依赖默认
旧版 Chrome（94–102）在未传 mode 时会静默 fallback 到 shared，而 shared 锁允许多个标签页同时进入回调——你以为加了锁，实际并发照旧。写操作必须用 exclusive，否则形同虚设。
-
navigator.locks.request('cart', cb)→ 风险：旧版 Chrome 当成shared，两个标签页同时调用setItem还是覆盖 -
navigator.locks.request('cart', { mode: 'exclusive' }, cb)→ 安全：明确语义，所有支持版本都按排他语义执行 - 读操作可选
shared，但只要涉及修改状态（哪怕只是 localStorage 标记），就必须用exclusive
锁名必须带业务唯一标识，否则“全局互斥”就变成“全局阻塞”
锁名就是作用域标识符。相同名字 = 同一资源级互斥。很多人用固定字符串如 'draft' 或 'cart'，结果用户 A 编辑自己的草稿时，用户 B 的草稿操作也被卡住——这不是 bug，是设计使然。
- 错：
navigator.locks.request('draft', cb)—— 所有草稿共享一把锁，互相阻塞 - 对：
navigator.locks.request(`draft-${docId}`, cb)或`user-cart-${userId}`—— 按资源或用户隔离 - 锁名需 URL-safe：避免空格、斜杠、控制字符；长度建议 ≤64 字符，过长（>256）可能影响内部哈希性能
ifAvailable: true 不是可选项，而是防 UI 卡死的底线
不传 ifAvailable: true，锁不可用时会无限等待，整个页面交互冻结。尤其在用户快速切换标签页或频繁触发写操作时，极易出现假死。
-
await navigator.locks.request(key, { mode: 'exclusive' }, cb)→ 危险：无超时、无 fallback，锁被占用即卡住 -
await navigator.locks.request(key, { mode: 'exclusive', ifAvailable: true }, cb)→ 安全：拿不到锁立即返回undefined，你可以提示“其他窗口正在编辑”或降级为只读 - 回调
cb必须返回 Promise，否则锁在函数退出后立刻释放——别写return 'done'这种同步返回
Safari 不支持是事实，服务端幂等才是兜底红线
截至 iOS 17.5 / macOS 14.5，Safari 仍无 navigator.locks 支持痕迹。仅靠 if ('locks' in navigator) 跳过逻辑，等于在 Safari 里彻底放弃互斥保障。
- 服务端必须做幂等：每个写请求附带客户端生成的
requestId，后端校验是否已处理过 - 前端轻量 fallback 可用
localStorage+storage事件模拟：写前存lock:cart-123:timestamp，监听到冲突则提示，但这不是强一致，仅作友好提示 - 真正容易被忽略的是锁的作用域边界：私有模式（隐身窗口）、不同源、跨设备，全部不共享锁——你测的“同源多标签页有效”，不代表用户真实场景全覆盖
