WebLocksAPI实现多标签页同步访问

Web Locks API 是一种轻量级前端机制，专为同源多标签页场景下实现单例资源的互斥写入控制而设计——它不提供权限同步、状态广播或跨会话持久化能力，仅确保“同一时刻至多一个标签页执行特定逻辑”；正确使用需严格遵循：锁名必须携带业务唯一标识且 URL-safe，mode 必须显式设为 'exclusive'，ifAvailable 必须启用以防 UI 卡死，同时必须为 Safari 等不支持环境准备服务端幂等兜底（如 requestId 校验）和前端轻量降级（如 localStorage + storage 事件提示），并清醒认知其作用域局限——仅限同一 origin、同一用户代理、同一常规浏览会话内有效，私有模式、跨源、跨设备均无法覆盖。

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 + 一个用户代理 + 一个常规浏览会话内生效。超出这个范围，得靠服务端协调或最终一致性方案来兜底。

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