不能直接解决，但能通过锁协调多标签写操作；需用 navigator.locks.request 包裹“打开DB→事务→写入→完成”整段逻辑，确保串行化，并 await tx.done 防提前释放锁。
Web Locks API 能否解决 IndexedDB 多标签写冲突？
不能直接解决，但能有效协调。Web Locks API 本身不操作数据库，它只提供跨标签页的互斥锁机制；IndexedDB 的事务隔离（如 readwrite 模式）仅在单个连接内生效，多个标签页各自打开的 indexedDB.open() 是完全独立的连接，写操作会竞态。真正起作用的是用锁把「打开 DB → 启动事务 → 写入 → 关闭」这一整段逻辑包住，强制串行化。
如何用 navigator.locks.request() 包裹 IndexedDB 写操作？
核心是把锁名与操作语义绑定，避免锁粒度太粗（影响并发）或太细（失效）。写操作必须等锁、读操作可选是否加锁（取决于一致性要求）：
async function safeWriteToStore(storeName, key, value) {
return navigator.locks.request('idb-write-lock', async (lock) => {
const db = await openDB(); // 自定义的 indexedDB 打开逻辑
const tx = db.transaction(storeName, 'readwrite');
const store = tx.objectStore(storeName);
await store.put(value, key);
return tx.done; // 等待事务完成再释放锁
});
}
-
'idb-write-lock'是全局唯一锁名，所有标签页用同一字符串才能互斥 - 锁在
request()回调执行完（或抛错）后自动释放，无需手动release() - 务必
awaittx.done，否则锁可能在事务实际提交前就释放，导致冲突 - 不要在锁内做耗时同步操作（如大数组遍历），会阻塞其他标签页
读操作要不要加锁？常见误判点
多数场景下读操作不需要锁 —— 如果你接受“最终一致”，比如用户列表刷新，用 readonly 事务读取即可。但以下情况必须加锁：
- 读-改-写（read-modify-write）流程，例如：读计数器 → +1 → 再写回
- 多个读操作之间有强顺序依赖，比如 A 标签页读到 v1 后才允许 B 标签页读 v2
- 读操作需要和某个写操作严格同步（如“写完配置后立刻读新配置”）
此时应使用相同锁名（如 'idb-write-lock'），或另建读锁（'idb-read-lock'），但需注意：读锁 + 写锁组合要小心设计，否则易死锁。
兼容性与降级处理怎么做？
navigator.locks 在 Safari 16.4+ 和 Chrome/Firefox 较新版本才稳定支持，Safari 早期版本返回 undefined。不能简单报错，得降级为“尽力而为”的协调：
- 检测
!navigator.locks时，走无锁逻辑，但给用户轻量提示：“多窗口编辑可能不同步” - 避免用
localStorage模拟锁（如轮询 flag），它没有原子性，竞态更严重 - 服务端最终校验仍是兜底方案：前端加锁只是优化体验，关键数据仍需后端幂等接口或乐观锁（
versionstamp）保障
真正的难点不在 API 调用，而在判断哪段逻辑该被锁、锁多久、以及当锁等待超时（比如用户切走半小时）时，是否中止还是重试 —— 这些都需要结合业务语义来定，不是套个 request() 就万事大吉。
