CreateInBatches默认不开启事务，某批失败时前面批次已提交，需显式用db.Transaction包裹；它仅按batchSize切片并逐批执行单条多值INSERT，错误只返回最后一批，不保证原子性。
事务必须显式开启，CreateInBatches 默认不进事务
很多人以为 CreateInBatches 自动包裹事务，结果某批失败时前面批次已提交，数据状态不一致。GORM 的 CreateInBatches 本质只是把切片按 batchSize 拆开、逐批执行单条多值 INSERT，它不开启、也不管理事务边界。
正确做法是手动用 Transaction 包裹：
- 调用
db.Transaction(func(tx *gorm.DB) error { ... })，在闭包内用tx.CreateInBatches(...) - 不要用
db.Begin()+tx.CreateInBatches()+tx.Commit()手动控制——GORM 的Begin()返回的是裸*gorm.DB，不是标准事务对象，嵌套或并发下易出错 - 若上游（如 HTTP handler）已开启事务，直接复用传入的
*gorm.DB即可，避免嵌套事务破坏一致性
批次大小设为 100–500，避开 MySQL max_allowed_packet
设太大（比如 5000）可能触发 MySQL 的 max_allowed_packet 错误（典型报错：ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes）。500 行 × 平均 2KB/行 ≈ 1MB，在默认 4MB 限制下安全。
不同数据库行为差异明显：
- MySQL：支持多值 INSERT，
CreateInBatches效率高 - PostgreSQL：默认启用
RETURNING，每批语句变复杂，性能略降；可关掉：db.Session(&gorm.Session{CreateBatchSize: 500}).CreateInBatches(...) - SQLite：根本不支持多值 INSERT，GORM 会退化为循环单条
INSERT，此时用CreateInBatches反而增加切片开销，建议换原生Exec拼接
错误只返回最后一批，想定位哪条数据失败得自己分批
CreateInBatches 返回的 error 是最后一组的失败原因，不是聚合错误。前 9 批成功、第 10 批因主键冲突失败 → 你只拿到第 10 批的错误，且前 9 批已写入（如果没包事务）。
要精准定位问题数据，得放弃“一键全量”，改用手动分批：
- 用
for i := 0; i - 每批单独调用
tx.CreateInBatches(batch, len(batch))，捕获并记录每批的error和起始索引 - 注意：
min需自己定义或用int(math.Min(float64(i+batchSize), float64(len(users))))
主键回填不可靠，尤其跨批或用 MySQL 时
MySQL 不支持 RETURNING，插入后 users[0].ID 仍是 0；PostgreSQL 虽支持，但仅限单批——多批调用时，clause.Returning 结果会错位，users 切片里的 ID 可能对应错行。
如果业务强依赖插入后的主键（比如后续要关联写入子表），别指望 CreateInBatches 自动赋值：
- MySQL 场景：插入后用
SELECT LAST_INSERT_ID()+ 行数推算范围，再查出来补 ID - PostgreSQL 场景：改用单批大尺寸（如 500），配合
RETURNING id获取完整 ID 列表，再按顺序映射回原始结构体 - 更稳方案：提前生成 UUID 或雪花 ID 作为主键，绕过数据库自增逻辑
事务控制、批次尺寸、错误定位、主键处理——这四点漏掉任一，批量插入就容易变成线上事故温床。尤其在微服务里，上游事务上下文和下游数据库能力常被忽略。
