GORM批量插入默认不事务安全，CreateInBatches仅拆分SQL并自动提交；必须用db.Transaction显式包裹才能保证原子性，否则部分失败会导致数据不一致。
GORM 批量插入本身不自动参与事务，必须显式开启事务并手动控制提交/回滚；否则 db.CreateInBatches 或 db.Session(&gorm.Session{PrepareStmt: true}).CreateInBatches 都只是“批量发 SQL”，不是“原子性写入”。
为什么 CreateInBatches 不等于事务安全
很多人误以为调用 db.CreateInBatches 就天然带事务保障，其实它只是把一批数据拆成多个 INSERT ... VALUES (...), (...), (...) 语句发出去，每条语句仍走 GORM 默认的自动提交逻辑（除非你禁用了默认事务）。一旦中途某批失败，前面成功的批次已落库，无法回滚。
- 默认行为：GORM 对单个
CreateInBatches调用不开启新事务，只复用当前会话的事务状态 - 常见错误现象：
db.CreateInBatches(&users, 1000)执行到第 3 批时 panic，前 2 批用户已入库，数据不一致 - 根本原因：
CreateInBatches是“批量发送”，不是“批量包裹”——它不创建事务边界
正确做法：用 db.Transaction 包裹批量操作
必须用 db.Transaction 显式启动事务，并在回调函数里执行批量插入。这样整个批次组才具备原子性。
- 事务内调用
CreateInBatches才真正生效：所有批次共享同一事务 ID，任一失败则全部回滚 - 注意传参方式：不要传指针切片（如
&users），而应传值切片（如users），避免事务内修改影响外部变量 - 若需分批处理超大数据（如 10 万条），可在事务内循环调用
CreateInBatches，但必须确保所有调用都在同一个tx对象上
// 正确示例
err := db.Transaction(func(tx *gorm.DB) error {
// 分 5000 条/批，共插入 10 万条
for i := 0; i < len(users); i += 5000 {
batch := users[i:min(i+5000, len(users))]
if err := tx.CreateInBatches(batch, 5000).Error; err != nil {
return err // 触发回滚
}
}
return nil // 提交
})
性能关键：关闭 PrepareStmt + 合理设 batch_size
批量插入性能瓶颈常不在事务逻辑，而在驱动层预编译和单次 SQL 长度限制。这两个参数直接影响吞吐量。
-
PrepareStmt: false可提升 20%~40% 写入速度（尤其 MySQL），因为跳过预编译开销；但要注意 SQL 注入风险仅存在于拼接字段名等非常规场景，CreateInBatches本身用参数化，安全 -
batch_size不是越大越好：PostgreSQL 推荐 ≤ 10000，MySQL 建议 ≤ 5000（受max_allowed_packet限制）；超过易触发Packets larger than max_allowed_packet错误 - 实测发现：对 50 万条用户数据，
batch_size=2000+PrepareStmt:false比默认配置快 3.2 倍
别踩坑：关联数据、钩子、软删除的干扰
批量插入时，GORM 的钩子（BeforeCreate 等）、关联预加载（Preload）、软删除字段（DeletedAt）默认都不生效——这是设计使然，但容易被忽略。
-
CreateInBatches绕过所有模型钩子，所以依赖BeforeCreate自动生成ID或时间戳的逻辑会失效，需提前赋值 -
Preload和Joins在批量插入中无意义，也不支持；若需关联写入，请用事务内分步操作（先插主表，再用返回 ID 插从表） - 软删除字段（
DeletedAt）不会被自动过滤，如果结构体字段为零值，会真实写入NULL，而非跳过；需手动置空或用Select()明确指定字段
最常被忽略的一点：事务内批量插入失败后，错误类型可能是 *mysql.MySQLError 或 *pq.Error，而不是通用 gorm.ErrRecordNotFound，做错误分类处理时得按驱动类型断言，否则兜底逻辑可能漏判。
