如何通过 Web Locks API 异步协调多个页面对共有 DOM 资源的原子化访问

有志者，事竟成！如果你在学习文章，那么本文《如何通过 Web Locks API 异步协调多个页面对共有 DOM 资源的原子化访问》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

Web Locks API 通过资源维度唯一锁名协调多标签页对共享状态的原子访问，所有读-改-写操作须在锁回调内完成并返回 Promise，不支持环境需服务端幂等或前端提示降级。

Web Locks API 不能直接锁 DOM 元素或操作 DOM，它协调的是“执行逻辑”的互斥，而非 DOM 本身。要实现多个页面对共有 DOM 资源（如共享的 localStorage 键、全局配置状态、计数器 UI 等）的原子化访问，关键在于：把读-改-写 DOM 相关状态的全过程包进锁回调，并确保该过程真正串行、无竞态。

以下三点是落地核心：

锁名必须按资源维度唯一，且 URL-safe
共用同一 DOM 资源的多个标签页，必须申请同一把锁；但不同资源之间不可互相阻塞。例如：

• ✅ dom-state-cart-${userId} —— 用户购物车状态变更
• ✅ dom-config-theme —— 全局主题设置（全站统一）
• ❌ 'cart' 或 'theme' —— 所有用户/所有配置全被串行，性能雪崩
• ❌ 'cart-' + Date.now() —— 每次锁名都不同，完全失效

所有修改动作必须在 request 回调内完成，且返回 Promise
DOM 相关的“共有资源”通常落地在 localStorage、sessionStorage 或 IndexedDB 中；而 UI 更新（如刷新计数 badge）应放在锁外。典型安全写法：

• 读取当前值（从 localStorage 或 indexedDB）
• 计算新值（简单逻辑，避免耗时计算）
• 写入存储（await localStorage.setItem 或 await tx.done）
• 必须 return 一个 Promise，且等待写入真正落地
  示例：

  await navigator.locks.request('dom-state-cart-123', { mode: 'exclusive' }, async () => {
  const cartStr = localStorage.getItem('cart-123') || '[]';
  const cart = JSON.parse(cartStr);
  cart.push(newItem);
  localStorage.setItem('cart-123', JSON.stringify(cart));
  // 注意：localStorage 是同步 API，但为保持模式统一，建议封装为 Promise
  return Promise.resolve();
  });

不支持环境必须降级，不能跳过逻辑
Safari（截至 iOS 17.5 / macOS 14.5）仍不支持 Web Locks API。仅靠 if ('locks' in navigator) 就跳过，会导致多标签页裸奔。可行降级策略：

• 服务端兜底：所有写请求携带客户端生成的 requestId，后端幂等处理（拒绝重复 ID）
• 前端轻量提示：用 localStorage 存时间戳 + storage 事件监听，检测到冲突时 UI 提示“其他窗口正在编辑”，不阻止但明确告知
• 切勿用 setTimeout 或随机退避模拟锁——这不是协调，是掩盖问题

锁只管“谁先执行”，不管“执行结果是否可见”。DOM 渲染更新（比如更新 ）应在锁释放后异步触发，避免阻塞锁持有时间。真正需要原子化的，是底层状态的一致性，不是视觉刷新的时机。

好了，本文到此结束，带大家了解了《如何通过 Web Locks API 异步协调多个页面对共有 DOM 资源的原子化访问》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！