在实际开发中，涉及唯一约束的业务场景（如用户注册、唯一编号数据写入），许多开发者首先想到的方案是“先查询是否存在，不存在再插入”——这在大多数具备一定编程经验的开发者看来，几乎是标准操作。
单元测试通过，低并发环境运行一切正常。然而当请求量增大时，日志中频繁出现“唯一键冲突”错误。此时许多开发者会困惑：明明已经判断不存在，为何仍然写入成功？
问题的根源在哪里？其实很简单：分步执行的查询和插入并非原子操作。在并发环境下，“先查后插”的流程天然存在竞态条件。下面我们拆解问题，并给出基于数据库原生能力的标准解决方案。
一、“先查后插”的并发安全漏洞
以用户表的邮箱唯一约束为例。典型的分步代码实现如下：
// 检查邮箱是否已注册var count int64db.Model(&model.User{}).Where("email = ?", email).Count(&count)if count == 0 { // 不存在则创建用户 db.Create(&newUser)}单线程执行时，这段代码毫无问题。但若两个相同邮箱的请求几乎同时到达，执行时序会交叉：
时间轴：T1 请求A执行SELECT -> 结果为0，判定邮箱未注册T2 请求B执行SELECT -> 结果为0，同样判定邮箱未注册T3 请求A执行INSERT -> 写入成功T4 请求B执行INSERT -> 触发唯一索引约束，返回 1062 Duplicate entry 错误
两个请求都在对方完成写入前完成了查询，均得出“数据不存在”的结论，后写入的那个自然撞上冲突。
更令人困扰的是，即便将这两步包裹在同一个数据库事务中，问题依然存在。在InnoDB默认的可重复读隔离级别下，普通SELECT是快照读，不会给不存在的行加锁，因此无法阻止其他事务的并发写入。事务只能保证自身操作的原子性，但无法填补分步判断留下的时间窗口。
二、基于数据库原生能力的原子写入方案
解决问题的核心思路，是将“判断+写入”合并为单条SQL操作，依靠数据库唯一索引的锁机制来保证执行原子性。MySQL提供了两种标准语法，对应不同的业务场景。
1. INSERT IGNORE：冲突时静默跳过
在INSERT语句中加上IGNORE关键字，一旦遇到唯一键冲突，数据库不会抛出错误，而是直接忽略本次写入，返回受影响行数为0。
INSERT IGNORE INTO users (email, name, password) VALUES ('a@example.com', '张三', 'encrypted_pwd');- 无冲突时正常写入，受影响行数为1
- 有冲突时静默跳过，无报错，受影响行数为0
此方案适用于幂等性写入场景，如批量数据导入、初始化数据去重。重复数据无需额外处理，通过受影响行数即可判断实际是否写入。其最大价值在于避免将正常业务冲突转化为系统错误，减少无效的错误日志。
2. ON DUPLICATE KEY UPDATE：冲突时执行更新
若冲突时需要更新部分字段，则使用此语法——即常说的Upsert（更新或插入）。唯一键命中时，执行后面的UPDATE逻辑；未命中时正常插入。
INSERT INTO users (email, name, last_login_time) VALUES ('a@example.com', '张三', NOW())ON DUPLICATE KEY UPDATE name = VALUES(name), last_login_time = VALUES(last_login_time);- 无冲突时执行插入，受影响行数为1
- 有冲突时执行更新，受影响行数为2
典型场景如用户登录态刷新、配置项写入——数据不存在则创建，存在则刷新。整条语句在数据库层面原子执行，没有任何并发窗口。
三、GORM中的工程化实现
GORM提供了clause.OnConflict原生支持上述两种冲突处理逻辑，无需手动拼接原生SQL。
冲突忽略模式
对应INSERT IGNORE语义，适合注册、幂等写入场景：
func (r *userRepo) CreateIfNotExist(ctx context.Context, user *model.User) (bool, error) { res := r.db.WithContext(ctx). Clause(clause.OnConflict{DoNothing: true}). Create(user) if res.Error != nil { return false, res.Error } return res.RowsAffected > 0, nil}调用方通过返回的布尔值判断实际是否创建成功，错误分支只处理真正的系统异常。
冲突更新模式
对应ON DUPLICATE KEY UPDATE语义，指定冲突时需要更新的字段：
func (r *userRepo) Upsert(ctx context.Context, user *model.User) error { return r.db.WithContext(ctx). Clause(clause.OnConflict{ Columns: []clause.Column{{Name: "email"}}, DoUpdates: clause.AssignmentColumns([]string{"name", "a vatar", "updated_at"}), }). Create(user).Error}Columns指定用于判断冲突的唯一键列，DoUpdates指定冲突发生后需要更新的字段列表。语义清晰，与数据库特性完美对齐。
误区：SELECT FOR UPDATE并非解决方案
有些开发者考虑在事务中使用SELECT ... FOR UPDATE加行锁以消除竞态。但这条路行不通——行锁的前提是数据行存在。
当查询的目标数据尚未写入时，查询结果为空，没有实际的行可施加行锁。两个并发事务都会查到空结果，然后都认为自己可以安全写入，最终仍然触发唯一键冲突。
间隙锁在部分场景下确实会对写入产生限制，但其生效条件与隔离级别、索引类型、查询范围高度相关，依赖间隙锁来保证写入安全并不稳定。相比之下，直接使用数据库原生的冲突处理语法，是成本最低、可靠性最高的方案。
实践总结
- 切勿再编写分步判断逻辑。只要存在并发可能，先查后插就一定有冲突概率，不应作为生产环境首选方案。
- 仅需去重、无需更新时：选择
INSERT IGNORE/OnConflict{doNothing: true}，通过受影响行数区分写入结果。 - 存在即需更新字段时：选择
ON DUPLICATE KEY UPDATE/OnConflict{DoUpdates}，实现原子Upsert。 - 唯一索引是基础前提。冲突处理语法依赖唯一索引才能生效，建表时约束必须完整——这是数据一致性的最后防线。
本质上，这是一个经典的工程设计原则：能通过底层组件的原子能力解决的问题，就不要在上层通过分步逻辑来模拟。数据库本身已提供成熟的并发写入处理机制，善用这些特性，既能减少代码复杂度，也能获得更可靠的并发表现。
