gorm 的 createinbatches 不具备容错能力，仅分批执行 sql，遇错即停；容错需手动实现重试、跳过、状态记录与断点续传。
直接说结论： GORM 本身不提供开箱即用的“分批分页容错机制”，CreateInBatches 只负责分批写入，失败即中断；真正的容错必须由你手动封装重试、跳过、状态记录和断点续传逻辑。
为什么 CreateInBatches 不等于容错
GORM 的 CreateInBatches 是纯批量插入工具，底层调用 INSERT ... VALUES (...), (...)。它只做两件事：按 batchSize 切分数据、逐批执行 SQL。一旦某一批遇到唯一键冲突、外键约束失败或网络超时，整个导入就 panic 或返回 error，不会自动跳过坏数据，也不会记住已成功写入多少条。
- 它不捕获单条记录级错误（比如某条
email重复，其余正常） - 它不保存中间状态，重启后无法从断点继续
- 它不区分错误类型——连接超时和数据校验失败都被当“失败”处理
如何手动实现带容错的分批导入
核心思路是：把“一批”再拆成“可恢复的原子单元”，并记录每批的执行结果。推荐结构如下：
- 用
for i := 0; i 手动切片，而非依赖 <code>CreateInBatches内部逻辑 - 每批用
tx.CreateInBatches(...)包裹在事务中，失败时tx.Rollback()，但保留错误批次索引 - 对每批结果，用
tx.Statement.RowsAffected校验写入数，或开启gorm.Config.SkipDefaultTransaction = true改用无事务裸写 + 每条FirstOrCreate防冲突（适合小批量高冲突场景） - 将失败批次的原始数据写入临时表或本地 JSON 文件，供人工审核或异步重试
示例关键片段：
for i := 0; i <h3>分页式导入 vs 分批式导入：别混用</h3> <p>“分页”在导入场景中常被误用。真实需求通常是：<strong>从上游源（如 CSV、API 分页接口）持续拉取数据，再分批写入本地库</strong>。这时要拆成两个独立控制流：</p>
-
拉取层：用
offset/limit或游标（cursor）从源系统分页读，注意避免 MySQL 的OFFSET深度翻页性能衰减 - 写入层：对每次拉到的数据块，走上面说的带容错的分批写入逻辑
- 两者之间必须加 checkpoint：例如把最后成功处理的
cursor值存到 Redis 或数据库，宕机后从该位置 resume
常见错误是试图用 SELECT ... LIMIT 1000 OFFSET 50000 直接查出全部数据再分批，这会把几十万行全 load 进内存，OOM 风险极高。
容易被忽略的三个硬伤
实际压测中，以下三点最容易在高负载下暴露：
-
db.Set("gorm:save_associations", false)必须显式关闭关联保存，否则每条记录触发 N+1 关联插入，吞吐量断崖下跌 - PostgreSQL 下若启用
ignore_conflicts（GORM v1.25+），需确认是否真的需要——它底层用ON CONFLICT DO NOTHING，但会静默丢弃冲突行，且不返回哪些被忽略，不利于审计 - MySQL 8.0+ 的
max_allowed_packet默认仅 4MB，batchSize=1000时极易超限，报错MySQL server has gone away，必须同步调大服务端与客户端配置
