CreateInBatches 更可靠因其单语句批量插入减少事务开销、连接瓶颈和锁时间，但需手动事务控制防部分失败，不自动分片或跳过脏数据，且各数据库行为差异大。
为什么 CreateInBatches 比循环调用 Create 更可靠
直接批量插入能避开事务开销、连接复用瓶颈和主键冲突风险。GORM 的 CreateInBatches 底层走的是单条 INSERT INTO ... VALUES (...), (...), (...) 语句（MySQL/PostgreSQL），不是多次 INSERT，所以吞吐高、锁时间短。
常见错误是误以为它会自动分片——其实它只负责按指定大小切片并逐批执行，每批仍是一次 SQL 执行；如果某一批里有重复主键或违反唯一约束，整批失败，不会跳过坏数据。
- 默认每批 100 条，可通过第二个参数调整：
CreateInBatches(&users, 500) - 不支持跨表批量（比如同时插
User和Profile），必须同类型切片 - 若结构体含
CreatedAt/UpdatedAt字段，GORM 会自动填充；但自定义字段（如CreatedBy）需提前赋值，不会自动注入
CreateInBatches 返回值和错误处理怎么写才不踩坑
它返回的是最后一批的 error，不是所有批次的聚合错误。也就是说：前 9 批成功、第 10 批失败 → 你只拿到第 10 批的错误，前面的已写入数据库，不会回滚。
典型误用是只检查最终 error 就认为“全量成功”或“全量失败”，结果数据状态不一致。
立即学习“go语言免费学习笔记（深入）”；
- 必须自己控制事务：
db.Transaction(func(tx *gorm.DB) error { return tx.CreateInBatches(...).Error }) - 想定位哪条数据出错？得手动分批调用 + 捕获每批 error，
CreateInBatches本身不提供明细位置信息 - 返回的
*gorm.DB对象里，RowsAffected是最后一批影响行数，不是总数；总数得自己算：len(users)
PostgreSQL 和 SQLite 下 CreateInBatches 的行为差异
MySQL 支持多值 INSERT，所以 CreateInBatches 效率高；PostgreSQL 虽也支持，但 GORM 默认开启 Returning（用于获取插入后的 ID），这会让单条语句变成带 RETURNING 的版本，某些场景下性能略降；SQLite 则根本不支持多值 INSERT，GORM 会退化为循环单条 INSERT —— 此时用 CreateInBatches 几乎没收益，还多一层切片开销。
- PostgreSQL 用户可关掉
Returning提升速度：db.Session(&gorm.Session{CreateBatchSize: 1000}).CreateInBatches(...)，但会丢失自增 ID 回填 - SQLite 场景建议改用原生
Exec拼接批量语句，或换轻量 ORM（如sqlc） - 所有方言下，
ON CONFLICT（PG）或ON DUPLICATE KEY UPDATE（MySQL）都不被CreateInBatches原生支持，得手写Exec
什么时候不该用 CreateInBatches
它适合“干净数据、结构确定、无复杂前置逻辑”的插入场景。一旦涉及关联预加载、条件过滤、字段动态计算或需要中间校验，硬套反而增加维护成本。
- 要插 10 万条但其中 20% 需根据另一张表查状态再决定是否插入？别用
CreateInBatches，先过滤再批量 - 字段值依赖函数（如
uuid_generate_v4()或NOW()）？GORM 不会帮你转成 SQL 函数，得用db.Exec("INSERT ... SELECT ...") - 插入后立刻要基于新 ID 做关联操作？
CreateInBatches返回的 ID 列表不可靠（尤其 PG+Returning 开启时），不如分小批并显式取 ID
批量插入真正难的从来不是语法，而是数据一致性边界在哪、失败后要不要重试、下游服务能否承受部分写入。这些没法靠一个函数兜底。
