IndexedDB 通过唯一索引、事务内手动校验、同步冲突降级及版本化乐观并发控制四层机制保障唯一性。唯一索引强制单字段唯一并抛出 ConstraintError；复杂场景需在 readwrite 事务中查询+条件写入；同步时用 UUID v4 降低冲突，配合服务端 409 处理；高频更新则结合 version 字段实现 CAS 式更新。
IndexedDB 本身不提供类似 SQL 中 UNIQUE 约束的声明式机制，但可以通过索引、事务控制和业务逻辑组合实现强唯一性保障与冲突应对。关键不在“有没有约束”，而在于“如何设计才能让唯一性可验证、可干预、可恢复”。
用唯一索引强制键级唯一性
IndexedDB 支持在对象存储（Object Store）上创建唯一索引，这是最接近数据库 UNIQUE 约束的底层能力：
- 创建时指定
{ unique: true }，如：objectStore.createIndex('email', 'email', { unique: true }) - 插入或更新时若违反唯一性，会抛出
DOMException（错误名ConstraintError），而非静默覆盖 - 该约束只作用于索引字段值，不支持复合唯一（如
(email, tenantId)），需拼接成单字段或用自定义校验
事务内手动校验 + 条件写入
当唯一性逻辑复杂（如多字段组合、范围唯一、软删除状态参与判断）时，仅靠索引不够，需在事务中主动控制：
- 先用
get()或index.get()查询是否存在冲突记录 - 根据业务规则决定是拒绝写入、合并数据，还是生成新 ID（如追加时间戳后缀）
- 所有读取和写入必须在同一个
readwrite事务中，避免竞态窗口 - 示例场景：用户注册时检查邮箱是否已被占用，且需排除已软删除的记录
离线同步中的冲突降级策略
本地唯一性保障只是第一步；跨设备/跨会话同步时，不同客户端可能各自生成“合法”但重复的 ID（尤其用时间戳或简单随机数），此时需额外一层协调：
- 前端生成 ID 推荐使用
crypto.randomUUID()（UUID v4），冲突概率趋近于零 - 同步时若服务端返回 409 冲突，应携带服务端已有记录 ID，前端据此做合并（如保留最新修改时间戳）或提示用户选择
- 避免依赖本地自增 ID——IndexedDB 没有 AUTOINCREMENT，模拟易出错，且无法跨设备对齐
版本化 + 乐观并发控制（OCC）
对频繁更新的记录，唯一性常伴随“不能覆盖他人修改”的诉求。这时可结合版本字段与条件更新：
- 每条记录存
version字段（数字或时间戳），每次更新递增或刷新 - 写入前读取当前 version，提交时用
put()并检查 version 是否未变（类似 CAS） - 失败则重试或触发冲突解决流程（如弹窗对比差异）
- 此模式天然规避“后写覆盖前写”，比锁更轻量，适合浏览器多标签页场景
