navigator.locks.query() 不能监控 localStorage 或 IndexedDB 的锁状态，因其仅管理跨线程/标签页的 Web Locks API 同步原语；localStorage 无公开锁机制，其隐式页面级互斥锁不可查询；IndexedDB 事务隔离由浏览器自动处理，开发者无法干预或观测底层锁。
navigator.locks.query() 不能用于监控本地存储（如 localStorage 或 IndexedDB）的锁状态，因为它与 Web Locks API 的作用范围完全无关——Web Locks API 管理的是跨线程/跨标签页的同步原语（如 SharedWorker、Service Worker、页面主线程之间），而 localStorage 本身没有公开的锁机制，也不支持查询或显式加锁；IndexedDB 的事务隔离由浏览器内部自动管理，开发者无法直接干预或观测其底层锁。
为什么不能用 query() 监控 localStorage
localStorage 是同步阻塞式 API，在同源下所有标签页共享同一存储空间，但浏览器对其读写采用隐式、不可见的“页面级互斥锁”。这种锁：
- 不暴露给 JavaScript，无法通过任何标准 API 查询或释放
- 在写操作（
setItem）期间会阻塞同源其他标签页对该存储的全部读写（包括getItem），可能引发 UI 卡顿甚至假死 - 不存在“死锁”概念（因无嵌套锁或超时机制），但存在竞态导致的数据覆盖（例如两个标签页同时读-改-写，后写者覆盖前者）
如何安全地协调多标签页对 localStorage 的访问
虽无法加锁，但可通过约定式策略规避冲突：
-
使用时间戳+版本号字段：每次写入前读取当前值，检查
updatedAt时间或version，若发现已被更新则放弃或合并 -
委托单点控制：用
BroadcastChannel通知所有标签页“我将修改”，其他页暂停写入并监听完成事件 -
改用 IndexedDB：它支持事务、游标、并发控制，且能通过
onblocked事件感知升级冲突，比localStorage更适合多标签协作场景
Web Locks API 的正确使用场景
navigator.locks.query() 仅返回当前页面持有的锁列表（名称、mode、clientId），适用于：
- 调试时确认某锁是否被意外长期持有（如忘记
unlock()） - 在
SharedWorker中协调多个页面对共享资源（如缓存刷新、上传队列）的互斥访问 - 结合
navigator.locks.request()实现带超时的临界区保护（注意：锁不跨域、不持久化，关闭页面即释放）
示例：检查是否有未释放的锁
navigator.locks.query().then(locks => {
locks.held.forEach(lock => {
console.warn(`Held lock: ${lock.name}, mode: ${lock.mode}`);
});
});
解决 IndexedDB 潜在阻塞问题的方法
虽然 IndexedDB 无死锁（事务自动回滚），但版本升级可能被旧连接阻塞。应对方式：
- 监听
onblocked事件，主动关闭已打开的数据库连接 - 避免长时间保持 open 连接，事务结束后及时释放 IDBRequest 和 IDBObjectStore 引用
- 使用
event.target.transaction?.abort()在异常时快速清理
