应主动检测并重试唯一索引冲突：冲突前用SELECT+INSERT/UPDATE配合事务或加锁；冲突时按数据库类型捕获特定错误码；冲突后采用幂等SQL或业务重试策略；源头上通过分散索引、预生成ID等降低冲突概率。
当插入或更新数据时触发唯一索引冲突，不能只靠数据库报错被动处理，而应主动检测 + 合理重试，避免业务中断或数据不一致。
冲突发生前：先查再操作（SELECT + INSERT/UPDATE）
适用于并发不高、数据量不大、对一致性要求严格的场景。核心是“读取判断 → 决策执行”，避免盲目插入。
- 先用 SELECT 检查目标值（如 username、email）是否已存在，WHERE 条件覆盖唯一索引列
- 若不存在，执行 INSERT；若存在，走更新逻辑或返回提示
- 注意：该方式在高并发下仍有极小概率出现“查不到→别人插入→自己插入失败”的竞态，需配合事务隔离级别（如 REPEATABLE READ）或加锁（SELECT ... FOR UPDATE）
冲突发生时：捕获异常并分类处理
不同数据库返回的唯一约束冲突错误码不同，需针对性识别，不可笼统 catch 所有 SQLException。
- MySQL：错误码 1062（Duplicate entry），SQLSTATE '23000'
- PostgreSQL：SQLSTATE 23505（unique_violation）
- SQL Server：错误号 2627 或 2601
- 应用层捕获后，明确区分是唯一索引冲突，而非主键缺失、字段超长等其他错误
冲突后重试：带策略的有限次重试
盲目无限重试会加剧数据库压力，应结合业务语义设计重试逻辑。
- 简单幂等写入：若操作本身可重放（如 UPSERT / MERGE），优先使用数据库原生语法（如 MySQL INSERT ... ON DUPLICATE KEY UPDATE，PostgreSQL INSERT ... ON CONFLICT DO UPDATE）
- 业务重试：如生成唯一订单号失败，可换随机后缀重试 3 次，每次 sleep 10–100ms 避免雪崩
- 记录日志 + 告警：首次冲突记录 warn 日志，连续多次失败升级为 error 并触发监控告警
预防优于补救：从源头降低冲突概率
很多冲突本质是设计或调用不合理导致，应在架构和编码阶段规避。
- 避免高频写同一索引值（如 status=‘processing’ 的批量更新引发热点行锁）
- 分散唯一性约束：用组合索引替代单列索引（如 (tenant_id, order_no) 替代 order_no），提升并发写能力
- 客户端预生成唯一标识（如雪花 ID、UUID v4/v7），减少服务端校验依赖
- 对非强唯一字段（如昵称），允许一定重复，用业务规则去重而非数据库强制约束
