Web Locks API 不能替代 IndexedDB 事务，但它是唯一能跨标签页串行化写操作的原生机制；必须将 openDB、事务创建、put() 和 await tx.done 全部包裹在 navigator.locks.request() 回调中，否则锁提前释放会导致静默覆盖。
Web Locks API 不能替代 IndexedDB 事务，但它是唯一能跨标签页串行化写操作的原生机制——不加锁，两个标签页同时 put() 同一条记录，必然发生静默覆盖。
为什么 navigator.locks.request() 必须包裹整个事务生命周期
IndexedDB 的 readwrite 事务只在单个连接内隔离；多标签页各自调用 indexedDB.open()，等于开了多个互不通信的数据库会话。锁若只包住 put() 调用，而没等 transaction.done 就释放，其他标签页可能在数据尚未落盘时就拿到锁并读到旧值。
- 必须把
openDB()、transaction创建、put()、await tx.done全部放在request()回调里 - 绝不能只
tx.commit()就结束回调——它不保证写入完成，tx.done才是真正的落地信号 - 如果事务出错（如
QuotaExceededError），锁仍会自动释放，无需lock.release()
lock 名设计直接影响并发能力和冲突范围
锁名不是随便拼的字符串，它决定了哪些操作会被强制排队。全局锁（如 "idb-write"）最简单，但会让所有写操作串行化，哪怕改的是用户头像和笔记内容这种完全无关的数据。
- 推荐按业务实体粒度命名：如
"lock:note_123"、"lock:user_456"，避免无关操作阻塞 - 不要混用语义：日志上报和用户配置共用
"idb-write-lock"，会导致用户点保存时卡在日志队列里 - 锁名不支持动态变量插值以外的逻辑，
"lock:${type}_${id}"是安全边界，别试图加时间戳或随机数
常见错误现象与对应防护点
很多“锁了还是丢数据”的问题，其实根本没锁对地方，或者忽略了 IndexedDB 自身的限制。
-
InvalidStateError在onupgradeneeded中高频出现：Web Locks 对 versionchange 事务无效，多个标签页同时触发升级时，浏览器会随机拒绝其中一个——必须提前用锁协调版本变更意图，或改用惰性升级策略 - Service Worker 中调用失败却无报错：Safari 16.3 及更早版本不支持，需检测
"locks" in navigator，降级为乐观校验（比对updatedAt时间戳） - 锁被阻塞但 UI 没反馈：
mode: "exclusive"默认无限等待，应配合ifAvailable或手动超时控制，避免用户以为页面卡死
真正难的不是加锁那几行代码，而是想清楚「哪段逻辑必须原子执行」和「锁的边界是否和业务语义对齐」——比如编辑笔记时，读取旧值、校验冲突、写入新值、更新本地缓存，这整条链路才是一次完整受保护单元，少包一环，锁就形同虚设。
