createinbatches默认不开启事务，某批失败时前序批次已提交且不会回滚；必须显式用db.transaction()包裹才能保证原子性，否则易导致数据不一致。
db.CreateInBatches 默认不回滚整批数据
很多人以为 CreateInBatches 天然带事务保障，其实它默认只是“分批执行”，不开启事务。某一批失败（比如第 3 批因唯一键冲突报错），前 2 批已经写入数据库，不会自动回滚——这是最常被忽略的脏数据来源。
常见现象：批量插入 1000 条用户，第 501 条因邮箱重复报 ERROR: duplicate key value violates unique constraint，但查库发现前 500 条已存在。
- 必须显式用
db.Transaction()包裹整个CreateInBatches调用 - 不要在事务里混用非 GORM 原生操作（如 raw SQL 或其他 DB 连接），否则可能绕过事务上下文
- 事务内避免长耗时逻辑（如 HTTP 请求、文件读写），防止锁持有时间过长引发死锁
多批写入时 Returning 主键回填不可靠
PostgreSQL 下想让 CreateInBatches 把生成的 ID 写回原始 struct 切片，得加 clause.Returning，但实际效果受限严重：
-
clause.Returning{Columns: []clause.Column{{Name: "id"}}只对单批生效；多批时返回结果顺序和切片顺序不保证一致 - MySQL 完全不支持
RETURNING，无论是否加 clause，users[0].ID插入后仍是 0 - SQLite 的 RETURNING 实现不完整，主键回填大概率失败
- 若业务强依赖插入后的 ID（比如立即做关联插入），建议改用单次
Create+ 手动事务控制，或接受“先插再查”
死锁错误需手动捕获并重试
GORM 不会自动重试数据库死锁，错误直接透传给上层。PostgreSQL 返回 ERROR: deadlock detected（错误码 "40P01"），MySQL 是 "Deadlock found when trying to get lock"（错误码 1213）。
- 不能靠
recover()或 panic 捕获，必须检查err.Error()或类型断言（如pgerr, ok := err.(*pgconn.PgError)） - 重试次数建议 ≤ 3，每次间隔用指数退避（如
time.Sleep(time.Millisecond * time.Duration(math.Pow(10, float64(i))))） - 重试前必须确保事务内操作幂等：避免发重复消息、调重复第三方 API、或更新非幂等字段（如
updated_at应设为当前时间而非自增） - 别在 HTTP handler 层写重试循环，应下沉到 service 方法内部统一处理
batch_size 设置不当会触发数据库级限制
CreateInBatches 的第二个参数不是越大越好。设成 10000，可能直接被 MySQL 拒绝，报错 ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes。
- MySQL 默认
max_allowed_packet = 4MB，按每行平均 200 字节估算，安全上限约 20000 行/批；但线上通常设为 100–500 更稳妥 - PostgreSQL 对单条 INSERT 多值语句长度无硬限制，但过大会增加解析开销和 WAL 日志压力
- 如果结构体含大量文本字段（如
description TEXT），batch_size 应进一步下调 - 可配合
db.Session(&gorm.Session{PrepareStmt: true})复用预编译语句，降低单批 CPU 开销，但不解决网络包大小问题
事务粒度控制的核心矛盾在于：既要最小化锁持有范围，又要保证业务原子性。批量操作中，把“全部成功或全部失败”当作默认假设，是最危险的认知偏差。
