navigator.locks 怎样避免多个标签页同时刷新同一资源

多个标签页同时打开同一个系统时，最容易重复的事情就是“刷新同一份资源”：每个页面都发现缓存过期，然后各自发起请求，再把结果写回共享缓存。要避免这个竞态，关键不是给每个标签页加一个本地布尔变量，而是让它们使用同一个锁名：

await navigator.locks.request('resource-refresh', async () => { ... })

把“检查缓存、请求资源、写入共享缓存”都放进这个异步回调里。同一来源的其他标签页会等待同名锁释放，或者使用 ifAvailable 直接放弃本轮刷新。Web Locks API 需要安全上下文，通常就是 HTTPS，并且锁只在同一来源内协调。

一句话：锁名要稳定且共享，临界区要覆盖完整异步刷新过程；如果页面不能等待，就用 ifAvailable，不要用 steal 当普通重试按钮。

为什么只锁住 fetch 还不够

假设两个标签页先后执行“读取缓存 → 判断过期 → fetch → 写缓存”。如果锁只包住 fetch，两个页面仍可能在锁外同时判断缓存已过期；第一个页面释放网络锁后，第二个页面仍会继续发起自己的请求。去重的边界应该从缓存判断开始，一直覆盖到写入共享缓存结束。

锁的释放由回调返回决定。回调是 async 函数时，里面的 await fetch() 和写缓存都完成后才会释放，因此不能在回调里启动异步任务却不等待它。

用一个稳定锁名包住刷新和写入

const CACHE_KEY = "resource-cache:v1";
const LOCK_NAME = "resource-refresh:v1";

function readCache() {
  // localStorage 只是示例共享缓存；真实项目可替换为 IndexedDB。
  try {
    return JSON.parse(localStorage.getItem(CACHE_KEY) || "null");
  } catch (error) {
    // 缓存损坏时按未命中处理，避免阻塞后续刷新。
    return null;
  }
}

async function refreshResource() {
  if (!("locks" in navigator)) {
    // 不支持 Web Locks 时必须走项目自己的降级策略。
    return refreshWithoutLock();
  }

  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 3000);

  try {
    await navigator.locks.request(
      LOCK_NAME,
      { ifAvailable: true, signal: controller.signal },
      async (lock) => {
        if (!lock) {
          // 其他标签页正在刷新，本页直接使用现有缓存或稍后重试。
          return;
        }

        const cached = readCache();
        if (cached && Date.now() - cached.savedAt 

这里的 ifAvailable: true 让未拿到锁的标签页快速返回。若业务要求每个页面都拿到最新值，可以去掉它，让请求排队；但仍建议设置 signal，避免页面无限等待。

ifAvailable、signal 和 query 怎么选

ifAvailable 适合“本轮没有抢到就算了”的后台刷新；回调会收到 null，这不是异常。signal 适合“最多等一段时间”的场景，锁尚未授予时中止会产生 AbortError。锁一旦已经授予，后续网络请求的耗时仍由你自己的 fetch 超时控制负责。

排查某个资源为什么一直拿不到时，可以读取锁管理器的快照：

async function inspectRefreshLock() {
  // query 返回当前来源的锁快照，不会替你释放任何锁。
  const state = await navigator.locks.query();
  return {
    held: state.held.filter((item) => item.name === LOCK_NAME),
    pending: state.pending.filter((item) => item.name === LOCK_NAME),
  };
}

held 表示已经持有的锁，pending 表示排队中的请求。它是某个时刻的快照，不是永久状态；诊断时要结合页面日志和请求超时一起判断。

锁名、降级和 steal 的边界

锁名是应用自己定义的资源标识。想协调同一资源的标签页必须使用完全相同的名字，建议把业务对象和版本写进去，例如 profile-refresh:v1:user-42，避免把互不相关的资源误合并。锁只在同一来源内有效，协议、域名或端口不同就不是同一个锁空间。

Web Locks 不可用时，不能假设 navigator.locks 一定存在。降级函数可以结合服务端幂等键、缓存版本、广播通知或业务允许的重复请求来设计；不要把 localStorage 的单次读写误当成跨异步操作的完整互斥锁。

steal: true 会释放同名的已持有锁并抢占它，可能让正在刷新资源的标签页收到中止结果。它适合确定持有者已经失联、且业务有恢复方案的异常场景，不适合每次请求失败后的常规重试。

常见问题

多个标签页需要同时读取，能共用一个锁吗？

可以考虑 mode: "shared"，但刷新并写入共享资源通常仍应使用默认的独占模式。读写混合时要先明确哪些操作只读、哪些操作会改变缓存。

把锁回调写成普通函数会怎样？

普通同步回调返回后锁就会很快释放；如果异步工作没有被返回的 Promise 覆盖，锁无法保护那段工作。需要等待网络或数据库操作时，使用 async 回调并等待完整任务。

能用锁保证页面一定拿到最新数据吗？

不能。锁解决的是同一来源内的协调，不替代服务端一致性、请求失败重试、缓存失效策略和跨来源通信。它能让刷新动作不重复，但最新数据仍取决于你的数据源和错误处理。