多个标签页同时读写同一份数据是前端开发中常见的痛点。比如用户打开了两个编辑页面修改同一篇文章草稿，或者两个标签页都在更新本地缓存的用户配置，如果没有互斥机制，后写入的数据往往会覆盖先前的修改，导致状态不一致。浏览器原生的 Web Locks API 正是为了解决这类跨标签页资源竞争问题而设计的。它基于源（origin）提供锁服务，同一个源下的所有标签页共享同一把锁。不过原生的 navigator.locks.request 采用回调方式，链式调用起来比较绕，尤其是配合异步操作时容易被回调地狱拖累。借助 jQuery 的 Deferred 对象和链式语法，我们可以把锁的申请封装成类似 $.ajax 的调用风格，让跨页面互斥逻辑更加清晰易维护。

本文会从 Web Locks API 的基础概念讲起，然后展示如何用 jQuery 封装出 $.lock 和 $.withLock 两个实用方法，最后通过一个共享计数器示例演示多个标签页如何安全地协作更新状态。同时我也会梳理几个容易踩坑的细节，比如锁的粒度控制、超时处理以及浏览器兼容性降级方案。

Web Locks API 基础与跨标签页互斥原理

Web Locks API 是挂在 navigator.locks 下的一组接口，核心方法只有一个：request(name, callback)。调用时传入一个锁名称和一个异步回调函数，浏览器会保证同一时刻同一个源下只有一个标签页能持有该名称的锁。当回调函数执行完毕（Promise resolve 或 reject）时，锁会自动释放。如果另一个标签页此时也在申请同一把锁，它会进入等待队列，直到前一个持有者把锁释放。

锁的名称是一个字符串，你可以按照资源类型自定义，比如 'user-profile-sync' 或者 'draft-editor'。回调函数会收到一个 lock 对象，但通常用不到，因为锁的释放完全由回调返回的 Promise 控制。下面的原生代码展示了如何保护一段异步写入逻辑：

// 原生 Web Locks API 用法
navigator.locks.request('my-resource-lock', async function(lock) {
  // 这里是临界区，同一时刻只有一个标签页能执行到这里
  const data = await fetchDataFromStorage();
  data.counter += 1;
  await saveDataToStorage(data);
  // 回调结束时锁自动释放，无论成功还是失败
});

需要注意，request 方法返回的 Promise 会在回调执行完成后才 resolve，而且如果回调抛异常，锁依旧会被释放。这套机制非常适合保护跨标签页的共享资源，但它要求开发者习惯回调写法，并且无法直接使用 try/catch/finally 来管理锁的生命周期。对于习惯了 jQuery 链式风格的团队来说，原生 API 显得有些反直觉，因此我们考虑封装一层。

另外，Web Locks API 还提供了 navigator.locks.query() 方法，可以查看当前源下有哪些锁被持有或等待。这个方法在调试时很有用，但封装时通常不需要调用它，除非你想做监控或诊断。

用 jQuery 封装 $.lock 与 $.withLock

jQuery 的 Deferred 对象可以很好地模拟异步锁的申请流程。我们的目标是创建一个 $.lock 方法，接收锁名称和回调函数，返回一个 jQuery Deferred，这样调用者就可以使用 .done() 和 .fail() 来处理结果。回调函数内部依旧可以返回 Promise 或直接执行同步代码，锁的释放由内部封装保证。

一个更常用的模式是 $.withLock，它接受锁名称和一个返回 Promise 的任务函数，整体包一层锁，执行完后自动释放。下面是具体的封装实现，代码中使用了 ES6 的 async/await 来简化 Promise 管理，同时保证 $.Deferred 能够正确透传结果：

(function($) {
  // 检查浏览器是否支持 Web Locks API
  function isSupported() {
    return 'locks' in navigator && 'request' in navigator.locks;
  }
  // 申请锁并执行回调，返回 $.Deferred
  function acquireLock(name, task) {
    var deferred = $.Deferred();
    if (!isSupported()) {
      deferred.reject(new Error('Web Locks API is not supported in this browser'));
      return deferred.promise();
    }
    navigator.locks.request(name, async function(lock) {
      try {
        var result = await task(lock);
        deferred.resolve(result);
      } catch (err) {
        deferred.reject(err);
      }
    });
    return deferred.promise();
  }
  // 暴露 $.withLock 方法
  $.withLock = function(name, task) {
    return acquireLock(name, task);
  };
  // 暴露 $.lock 方法，支持更细粒度的控制
  $.lock = function(name) {
    var api = {
      run: function(task) {
        return acquireLock(name, task);
      }
    };
    return api;
  };
})(jQuery);

上面的封装有两个入口：$.withLock 适合一次性执行任务，而 $.lock 返回一个带 run 方法的对象，方便在需要时再执行任务。实际使用中，$.withLock 更加简洁，比如读取并更新共享状态时，可以这样写：

$.withLock('shared-counter', async function() {
  const current = await readCounterFromStorage();
  const updated = current + 1;
  await writeCounterToStorage(updated);
  console.log('更新后计数为', updated);
}).then(function() {
  console.log('锁内任务执行成功');
}).catch(function(err) {
  console.error('执行失败或浏览器不支持', err);
});

封装后的调用方式与 jQuery 的异步操作风格保持一致，开发者不需要关心锁的释放细节，也不需要写嵌套回调。如果任务内部抛出异常，锁依然会被正确释放，然后通过 .catch() 传递给调用者。

实际应用场景与常见注意事项

跨标签页资源互斥的应用场景比想象中要多。比如播放器音量同步：用户在两个标签页中打开了同一个音乐播放器，如果两个页面都往 localStorage 里写音量值，最后一次写入会覆盖前一次，但用户实际调整的顺序可能不是最后写入的那个。通过 $.withLock('volume-sync', ...) 保护读写操作，就能保证每次调整都基于最新的值。再比如多标签页协作的 Todo 列表，或者共享的购物车状态，只要涉及多个标签页读写同一份数据，锁都是一个有效的解决方案。

使用 Web Locks API 时有几个细节需要特别留意。第一是锁的粒度，锁名称应当尽量具体，避免所有操作都抢同一把全局锁造成不必要的阻塞。比如按资源 ID 拼接锁名：'todo-list-' + listId。第二是超时处理，原生 API 本身不提供获取锁的超时机制，如果某个标签页持有锁后因为进程挂起等原因一直不释放，其他页面就会无限等待。可以在任务内部添加自己的超时逻辑，或者借助 AbortSignal 与 request 的第三参数配合实现。第三是浏览器兼容性，Web Locks API 目前仅在 Chrome 69+、Edge 79+、Firefox 96+ 等较新版本中可用，对于不支持的浏览器，需要提供降级方案。

降级方案通常使用 localStorage 配合时间戳模拟互斥锁。原理是写入一个带过期时间的锁标识，申请锁前先检查并尝试写入，写入成功则视为获取锁。但这种方式不具备强一致性，只能作为临时兜底。以下是一个简单的降级实现，可以并入前面的封装逻辑：

// localStorage 降级锁实现
function acquireLegacyLock(name, task) {
  var deferred = $.Deferred();
  var lockKey = 'lock:' + name;
  var now = Date.now();
  var expiredAt = now + 5000; // 5秒超时
  var stored = localStorage.getItem(lockKey);
  if (stored && parseInt(stored, 10) > now) {
    deferred.reject(new Error('锁已被占用，请稍后重试'));
    return deferred.promise();
  }
  localStorage.setItem(lockKey, String(expiredAt));
  try {
    var result = await task();
    deferred.resolve(result);
  } catch (err) {
    deferred.reject(err);
  } finally {
    localStorage.removeItem(lockKey);
  }
  return deferred.promise();
}

需要注意的是，localStorage 的锁不是跨标签页实时的，它依赖轮询或者页面事件，而且极端情况下两个标签页同时写入也不会被阻止，所以只能作为不支持 Web Locks API 时的降级路径，不能替代原生锁。另外在代码块中出现的 > 符号已经做了 HTML 转义，确保代码块能正常渲染。

总结与选型建议

通过 jQuery 封装 Web Locks API，我们获得了一个简洁、链式、可读性强的跨标签页互斥工具。对于已经大量使用 jQuery 的项目，这种封装几乎零成本接入，而且能够与现有 $.ajax、$.Deferred 风格保持一致。对于新项目，如果不需要 jQuery，直接使用原生 Promise 封装同样可行，核心思路完全一致。

是否需要跨标签页锁取决于你的应用是否真的存在多标签页并发写同一数据的场景。如果只是单页面内的异步竞争，使用 Promise 队列或者简单的本地锁就足够了，不必引入 Web Locks API。但如果你做的是协作编辑、多窗口状态同步、或者资源缓存管理，那么 Web Locks API 会是一个非常值得投入的原生能力。

最后提醒一点：锁的使用要有节制，过度同步可能导致标签页之间互相等待，影响用户体验。在设计锁策略时，优先考虑将临界区缩小到最小的读写操作上，并设置合理的超时。借助本文介绍的封装方法，你可以很方便地在项目中试验和调整锁的粒度，而不必改动太多业务代码。