Web Locks API 怎么防止多标签页重复刷新：ifAvailable、超时与失联恢复

后台系统开多个同源标签页时，订单列表、未读数和本地缓存很容易同时触发重复刷新。只靠页面内定义的布尔变量根本拦不住其他标签页，因为每个标签页都有独立的JavaScript执行上下文，这种场景下更适合把跨页写入的互斥协调交给浏览器原生的Web Locks API来处理。

多标签页重复刷新，真正冲突的是哪一段

假设每个页面启动后都会自动执行 syncOrders()：请求服务端数据、合并本地变更、写入IndexedDB，再更新页面上的未读提示。三个标签页几乎同时进入这段逻辑时，网络请求本身完全可以并行，但「读取旧版本数据—合并变更—写回存储」的部分不能随意并行，否则最后完成写入的页面很可能覆盖其他页面刚同步完的更新结果。

Web Locks的价值不是强制所有网络请求排队，而是把需要互斥保护的短操作区间命名为同一把锁。锁按origin做隔离，https://app.example.test 和另一个端口的同域名站点不属于同一把锁的控制范围；普通标签页和同域Worker之间可以加入同一个origin下的锁协调体系。

先用独占锁包住真正的写入区间

最基础的写法就是让锁的异步回调直接返回Promise。回调内部的Promise执行完成后，锁会被浏览器自动释放，所以不要在回调函数外部继续修改同一份跨页共享的本地数据。

async function syncOrders() {
  if (!navigator.locks) {
    return syncOrdersWithoutLock();
  }

  return navigator.locks.request('orders-sync', async (lock) => {
    const snapshot = await fetch('/api/orders?since=cursor-42').then((r) => r.json());
    await putOrdersAndCursor(snapshot);
    return { cursor: snapshot.nextCursor };
  });
}

默认的锁模式就是 exclusive。网络请求是否允许并发完全看业务设计；如果写入前必须先确认服务端返回的游标版本，就把拉取、校验和写回全流程放在同一个锁回调里。反过来锁的包裹范围太大，也会因为慢网络请求阻塞其他标签页的操作，实际开发项目时建议记录每次持锁的耗时。

只允许一个标签页刷新时，ifAvailable 比排队更合适

轮询定时触发、窗口重新获得焦点这类场景下的刷新请求，根本不值得让用户排长队等待。ifAvailable: true 会尝试立刻获取锁资源；如果当前已经有其他持有者占用锁，回调仍然会正常执行，但传入的参数是 null，调用方直接安静结束后续流程就好。

async function refreshOnce() {
  return navigator.locks.request(
    'orders-sync',
    { ifAvailable: true },
    async (lock) => {
      if (!lock) {
        return { skipped: true, reason: 'another-tab-is-syncing' };
      }

      const data = await readRemoteOrders();
      await putOrdersAndCursor(data);
      return { skipped: false, cursor: data.nextCursor };
    },
  );
}

这里的「跳过本次刷新」是正常的业务结果，不要把它当成系统错误上报。需要让用户看到最新数据时，可以在收到跨页消息通知后直接重新渲染；如果项目没有做跨页通知机制，也可以留到下一轮定时刷新时再尝试执行同步逻辑。

等待锁要有时间边界，但别把 steal 当作超时方案

有些操作确实需要等待前一个写入者完全完成，比如用户主动点击页面上的「立即同步」按钮。这时可以给锁请求挂上 AbortSignal，在超过预设的等待预算后直接退出等待队列。

async function syncWithDeadline(waitMs = 1500) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), waitMs);

  try {
    return await navigator.locks.request(
      'orders-sync',
      { signal: controller.signal },
      async () => {
        const data = await readRemoteOrders();
        await putOrdersAndCursor(data);
        return { cursor: data.nextCursor };
      },
    );
  } catch (error) {
    if (error?.name === 'AbortError') {
      return { skipped: true, reason: 'lock-wait-timeout' };
    }
    throw error;
  } finally {
    clearTimeout(timer);
  }
}

signal 只作用于还没拿到锁的排队请求；一旦回调已经成功拿到锁，后续业务逻辑不会因为这个信号自动中断执行。steal: true 则是完全不同的语义：它会主动释放同名的已持有锁并抢先执行当前逻辑，但原来持锁的页面代码可能还在继续访问共享资源，两个上下文很可能同时发起写入操作。只有在已经确认原持有者页面已经失联、且业务本身自带版本号或幂等保护机制时，才可以考虑使用这个特性。

用 query() 看清是已持有还是排队中

只返回「同步卡住」这类模糊信息算不上合格的诊断提示。可以把锁管理器返回的状态快照接入调试日志，重点看 held 和 pending，同时给每次发起的业务操作附上独立的请求ID方便排查。

async function inspectSyncLock() {
  if (!navigator.locks?.query) return null;

  const snapshot = await navigator.locks.query();
  return {
    held: snapshot.held.filter((item) => item.name === 'orders-sync'),
    pending: snapshot.pending.filter((item) => item.name === 'orders-sync'),
  };
}

快照只是查询瞬间的状态记录，不是长期有效的租约，也不能单凭这个结果断言某个标签页一定还处于活跃状态。更稳妥的做法是把持锁开始、完成、异常、等待超时这几个节点全部写入埋点，最终还是以服务端返回的游标或者版本号作为最终的冲突判断依据。

浏览器不支持时，降级策略要保持同一套业务门禁

Web Locks 使用前要先做能力检测。如果浏览器不支持这个API，不要指望靠页面内的本地变量实现跨标签页互斥；可以选择用服务端幂等键、带版本条件判断的写入接口，或者直接把本次刷新降级成只读请求。降级后的实现逻辑仍然要做游标校验、版本比对和重复提交拦截，不能只替换一行API调用就完事。

常见问题

Web Locks 能锁住不同域名的页面吗？

不能。锁仅在同一个origin范围内生效，协议、主机名或者端口任意一项不同，都会被划分为不同的协调域。

ifAvailable 没拿到锁会抛异常吗？

正常情况下不会因为「当前锁不可用」抛出异常，回调会收到 null。业务逻辑要把这种情况当成一次可接受的正常跳过。

steal 能解决页面崩溃后的死锁问题吗？

它可以用在明确知晓上下文的恢复场景，但旧的持锁逻辑可能还在后台运行，不能把它当成百分百安全的强制超时方案。优先用更小的临界区、AbortSignal和版本校验机制规避死锁。

锁回调里能一直等待用户点击操作吗？

技术上确实可以实现，但这么做会长期占用锁资源，阻塞其他所有标签页的同类型请求。更合理的方案是直接结束临界区，把当前状态写入本地存储，等用户确认操作后再重新申请锁执行后续逻辑。

把锁当成协调工具，而不是数据一致性的全部

Web Locks 非常适合解决「同一个origin内谁先执行本次刷新或写入」的问题：用独占锁保护短操作区间，用 ifAvailable 过滤重复触发的请求，用 signal 限制最长等待时长，用 query() 留全链路诊断痕迹。真正需要跨设备、跨进程或者抗重放的强一致性保障，还是要交给服务端版本控制、幂等键和可重试的业务协议来实现。