Web Locks API的核心能力是提供浏览器内核级的跨上下文（标签页、Worker、Service Worker）命名锁协调机制，具备原子性、排他性、自动释放及无阻塞异步接口，支持Exclusive/Shared/Upgrade三种锁模式，用于解决共享资源竞争与实现主从选举等高级同步场景。
什么是 Web Locks API 的核心能力
Web Locks API 提供了一种轻量级、跨标签页的同步原语，允许浏览器内多个执行上下文（如不同标签页、iframe 或 Service Worker）竞争获取同一把命名锁。它不依赖服务器或 localStorage 轮询，而是由浏览器内核直接协调，具备原子性、排他性和自动释放特性（如页面关闭时锁自动释放）。这使其天然适合实现“主从选举”——即多个实例中仅一个能长期持有“master”锁，其余作为待命的“slave”。
主从节点自动选举的基本流程
选举逻辑围绕一个固定锁名（如 "master-lock"）展开，所有标签页启动时尝试争抢该锁；成功获得者成为 master，失败者进入监听+重试循环。关键在于避免竞态和饥饿：
- 立即尝试 + 指数退避重试：首次 acquire 失败后，不要立刻重试，而是用 setTimeout 配合递增延迟（如 100ms → 200ms → 400ms），降低冲突概率
-
监听页面可见性变化：当 tab 切为后台（
document.hidden === true），主动 release 锁，让其他前台 tab 有机会接任；切回前台时重新尝试 acquire - 绑定锁生命周期到页面状态：master 页面关闭、崩溃或导航离开时，锁自动释放，无需手动清理
维持主节点状态与从节点同步机制
锁本身只保证“谁是 master”，不传递数据。因此需配合其他机制维持状态一致性：
- master 使用 BroadcastChannel 主动广播状态：如当前播放进度、编辑光标位置、连接状态等，所有标签页监听同名 channel，slave 收到后更新本地 UI（但禁止反向操作）
- slave 仅读取、不写入共享状态源：例如共享的 IndexedDB 表或 localStorage key，master 独占写权限，slave 定期 read（或监听 storage event）来对齐视图
-
加入心跳保活（可选）：master 每 5 秒调用
navigator.locks.request("master-lock", { ifAvailable: true }, ...)尝试续锁，若失败说明已被抢占，立即降级为 slave 并停止广播
实际代码结构要点
核心逻辑应封装为可复用模块，避免每个页面重复判断：
- 初始化时调用
navigator.locks.request("master-lock", options, callback)，其中options.steal: true允许强占（适用于 master 崩溃后快速恢复） - callback 中根据是否拿到锁，分别执行
becomeMaster()或becomeSlave() - 在
becomeMaster()内启动 BroadcastChannel 发送、设置 visibilitychange 监听、开启心跳；在becomeSlave()内订阅 broadcast、注册 storage listener、清空自身定时器 - 务必捕获
DOMException: The operation was aborted（锁被其他上下文释放时 request 被中断），并安全降级
