Web Locks API 实现 IndexedDB 并发写保护方法

Web Locks API 是浏览器中唯一能跨标签页实现 IndexedDB 写操作串行化的原生方案，但其正确使用极具陷阱：必须将数据库打开、事务创建、数据写入（put）及关键的 `await tx.done` 全程包裹在 `navigator.locks.request()` 回调内，否则锁提前释放将导致静默数据覆盖；锁名需按业务实体粒度精确设计（如 `"lock:note_123"`），避免全局锁扼杀并发性能或语义混用引发意外阻塞；更需警惕常见误区——如在 `onupgradeneeded` 中误用锁、Safari 旧版兼容缺失、无限等待无 UI 反馈等。真正挑战不在于代码行数，而在于精准界定“原子业务单元”并让锁边界与真实业务语义严丝合缝——少包一环，锁即失效。

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 或手动超时控制，避免用户以为页面卡死

真正难的不是加锁那几行代码，而是想清楚「哪段逻辑必须原子执行」和「锁的边界是否和业务语义对齐」——比如编辑笔记时，读取旧值、校验冲突、写入新值、更新本地缓存，这整条链路才是一次完整受保护单元，少包一环，锁就形同虚设。

到这里，我们也就讲完了《Web Locks API 实现 IndexedDB 并发写保护方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！