摘要

  • W3C 于 2023 年 1 月 5 日发布的 Web Locks 首份公开草案，让共享存储空间的窗口和 worker 对同一个自定名称异步申请锁。2025 年 9 月 24 日的工作草案沿用“申请、在回调中工作、完成后释放”的流程。
  • 独占锁在同名工作上只允许一位持有者，共享锁则允许兼容的持有者同时进入。例外的 steal 可以夺走旧锁，却未必让旧标签页的代码停手。

问题不在于两个标签页都坏了。恰恰相反，它们都好好地运行着，才可能同时去清理缓存、改写本地状态，或把一份文档同步到服务器。每个标签页只看见自己的执行过程；它们共同驻留的浏览器却看得见两位申请者。把等候和轮到谁这件事交给浏览器，是比事后修理重复工作更早的一道关口。

W3C 2023 年 1 月 5 日首份公开工作草案描述了 Web Locks 的基本动作：脚本异步取得一个命名资源的锁，做完工作后释放。同一存储桶内的窗口与 worker 可以借此协调。名称由应用自行选择，代表抽象资源。叫作 document-sync 的锁，不会变成操作系统里的实体文件锁；它只让约定同一名称的应用部件来到同一个门口。

W3C 出版记录列出 2023 年首份公开草案和 2025 年工作草案。2025 年 9 月 24 日版本把使用步骤写得干净：提出请求、持锁执行异步任务、任务结束时自动释放。它举出同一在线文档在两个标签页里编辑的例子，要求本地持久化与同步有序进行；另一个例子让“主标签页”独自承担清理或网络同步，主标签页关闭后，等候者可以接棒。

门口的规则由模式决定。独占模式让某个名称只有一位持有者；其他同名申请等待。共享模式允许数位共享持有者并行，但申请独占的写入者仍得等候。像阅览室可以同时坐几位读者，而改档案时要把桌面空出来。关键在名称的一致性：两个标签页如果给同一份状态取了两个不同的锁名，浏览器会开两道门，它们也就不会相遇。

W3C 规范仓库的说明文档进一步解释了回调与诊断快照。请求返回的 Promise 跟随回调结果；快照可以列出已持有和等待中的锁，但列表读到手时状态就可能变了。说明文档还摆出老牌死锁：甲握着 A 等 B，乙握着 B 等 A。浏览器可以忠实地维护两个队列，应用却设计了一场谁也无法先散席的会面。

最危险的捷径叫 steal。2025 年草案允许新申请把同名旧锁移走，并插到等待队伍前面。说明文档警告：旧标签页的代码可能继续运行，仍以为自己拥有独占权。号牌换了人，车间里的前一位工人却还在拧螺丝。应用若要用这条紧急通道，必须处理旧工作仍在继续的后果。

这台取号机也有地界。草案把协作范围放在同一浏览器中共享存储桶的执行单元；其他浏览器配置、隐私会话和别的设备有自己的锁管理器。四份官方原始记录讲清了机制与文档年代，没有替某个网站证明写入已完成。锁负责谁先进门，门内的工作是否正确，还得靠应用和存储结果说话。