多标签页协调资源访问，navigator.locks使用详解

`navigator.locks` 并非权限同步工具，而是一种轻量级、同源标签页间互斥执行的协调机制——它仅确保同一时刻至多一个标签页运行特定逻辑，不广播状态、不跨浏览器、不持久化，且 Safari 完全不支持；正确使用需严格遵循：锁名必须携带业务唯一标识并 URL-safe，mode 必须显式设为 `'exclusive'`，`ifAvailable: true` 为交互底线，锁内只包裹原子性读-改-写操作（严禁 fetch、DOM 渲染等副作用），而真正的可靠性根基永远是服务端幂等设计与客户端降级策略，而非过度依赖前端锁。

锁名必须带业务唯一标识，否则所有用户互相阻塞

用固定字符串如 'system-resource' 当锁名，会导致用户 A 和用户 B 编辑各自资源时相互抢占，这不是 bug，是设计：锁名即作用域。

• 错：navigator.locks.request('system-resource', cb) —— 全局一把锁，所有请求排队
• 对：navigator.locks.request(`system-resource-${resourceId}`, cb) 或 `system-resource-user-${userId}`
• 锁名需 URL-safe：避免空格、/、\0；长度建议 ≤64 字符，过长可能影响内部哈希性能

mode 和 ifAvailable 必须显式设置，否则行为不可控

不传 mode，旧版 Chrome 会静默 fallback 到 'shared'；不传 ifAvailable: true，锁不可用时 UI 直接卡死。

• 写操作必须用 mode: 'exclusive'，读-改-写流程也属于写
• ifAvailable: true 是高交互场景底线，配合超时更稳妥：{ ifAvailable: true, signal: AbortSignal.timeout(3000) }
• 回调函数必须返回 Promise，否则锁在函数退出时立即释放——别写 return 'done' 这种同步返回

锁内只包「读-改-写」原子段，别做耗时副作用

锁持有时间越长，其他标签页排队越久；上传、加密、DOM 渲染、大数组遍历等操作必须移出锁外。

• 正确姿势：await navigator.locks.request(key, { mode: 'exclusive', ifAvailable: true }, async () => { const data = await readFromIDB(); const next = compute(data); await writeToIDB(next); return tx.done; })
• 错误姿势：在锁回调里调用 fetch()、localStorage.setItem()、JSON.stringify(bigObj)
• localStorage 完全无法被 navigator.locks 协调——它是同步 API，锁根本插不进去

Safari 不支持是事实，服务端幂等才是兜底底线

iOS 17.5 / macOS 14.5 的 Safari 仍无 navigator.locks 支持痕迹。仅靠 if ('locks' in navigator) 跳过，等于在 Safari 里彻底放弃互斥保障。

• 服务端必须校验客户端传来的 requestId，拒绝重复 ID 的写请求
• 前端可轻量 fallback：用 localStorage.setItem('lock:system-' + resourceId, Date.now() + '') + storage 事件监听，仅作提示（“其他窗口正在操作”），非强一致
• 别在锁失败时直接报错退出——得降级为乐观更新或重试策略，用户流程不能断

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~