如何通过navigator.locks实现多标签页对唯一系统资源访问权限的精细协调？

本文共计988个文字，预计阅读时间需要4分钟。

许多人在直接使用`cart`或`draft`这类泛化名称时，结果会导致用户A编辑自己的购物车时，用户B的操作也被阻止——这不是权限控制，而是全局冻结。锁定的名称本质上是作用域标识符，而非描述性标签。

正确做法是把资源实例 ID 编进锁名：update-cart-${userId}、edit-draft-${docId}、sync-preferences-${accountId}。注意：必须 URL-safe（避免空格、斜杠、非 ASCII 字符），长度建议 ≤64 字符，过长可能影响内部哈希性能。

常见错误现象：

• 多个用户共用一把锁，导致无关操作互相阻塞
• 锁名含动态时间戳或随机数，使每次请求都生成新锁，完全失去互斥意义
• 未做转义，比如 docId 包含 / 导致锁名非法（浏览器静默失败或抛 TypeError）

mode 必须显式设为 'exclusive'，shared 模式对写操作无效

shared 模式只适合纯读场景（如多标签页同时 getItem），一旦涉及写入（put、set、delete），就必须用 exclusive。不传 mode 参数时，旧版 Chrome 会静默 fallback 到 shared，结果锁形同虚设。

示例写法：

await navigator.locks.request('edit-draft-abc123', { mode: 'exclusive' }, async (lock) => { // 此处执行读-改-写逻辑 });

关键点：

• 别依赖默认值，始终显式声明 mode: 'exclusive'
• 不要在锁回调里做条件分支后混用 shared 和 exclusive —— 锁一旦获取，mode 就已固定
• shared 锁之间不互斥，但会阻塞后续的 exclusive 请求；所以混合使用反而加剧排队

ifAvailable + signal 是防 UI 卡死的底线配置

navigator.locks.request() 默认会无限等待锁释放，一旦某个标签页异常卡住（比如锁内 Promise 没 resolve、页面崩溃未释放），其他所有标签页就永久挂起。真实业务中必须加保护。

推荐组合：

• ifAvailable: true：锁不可用时立即返回 undefined，不等待
• signal 配合 AbortController 设超时（如 3–5 秒），避免长时间无响应

示例：

const controller = new AbortController(); setTimeout(() => controller.abort(), 3000); try { await navigator.locks.request('edit-draft-abc123', { mode: 'exclusive', ifAvailable: true, signal: controller.signal }, async (lock) => { // 执行关键逻辑 }); } catch (err) { if (err.name === 'AbortError') { // 处理超时：提示用户“正在编辑中，请稍后再试”或降级为只读 } }

Safari 不支持，服务端幂等是唯一兜底方案

截至 2026 年 4 月，Safari（包括 iOS 17.5 / macOS 14.5）仍完全不支持 navigator.locks。仅靠 if ('locks' in navigator) 判断就跳过逻辑，等于在 Safari 里彻底放弃互斥保障。

真正可行的兜底策略只有两个方向：

• 服务端强制幂等：所有写请求携带客户端生成的 requestId，后端按 ID 去重或校验版本号（如 ETag、_rev 字段）
• 前端轻量协调作为友好提示：用 localStorage 存临时标记（如 lock:edit-draft-abc123:ts），配合 storage 事件广播，但不保证强一致

最容易被忽略的是锁的作用域边界：私有模式窗口、不同源页面、跨设备访问，全部不共享锁。你设计的「唯一系统资源」如果需要跨这些边界生效，navigator.locks 从一开始就不适用。