createinbatches 比循环 create 快得多，因其将多条记录合并为单条批量 insert 语句执行，跳过逐条事务开销、减少网络往返与 sql 解析，并仅触发一次 beforecreate/aftercreate 钩子；默认每批 100 条，需注意参数顺序、返回值检查方式及空切片安全行为。
为什么 CreateInBatches 比循环 Create 快得多
因为单条 Create 默认开启事务、走完整钩子链（BeforeCreate、AfterCreate）、每条都触发一次 SQL 解析和网络往返；而 CreateInBatches 把多条记录合并成一批，用一条 INSERT INTO ... VALUES (...), (...), (...) 执行，跳过中间事务开销，钩子也只跑一次（除非显式开启 AllowGlobalUpdate 或手动控制）。
常见错误现象：for _, u := range users { db.Create(&u) } 插入 1000 条耗时 3s+；换成 CreateInBatches 后降到 200ms 左右——差距主要来自 TCP 往返和事务 commit 频率。
- 默认每批 100 条（
db.CreateInBatches(users, 100)），不是越多越好：MySQL 单次 INSERT 有max_allowed_packet限制，超限会报错ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes - PostgreSQL 对 VALUES 列表长度也有硬限制（约 65535 个参数），实际建议单批 ≤ 5000 条
- 如果结构体带
gorm.Model，自增 ID 在批量插入后不会自动回填到 struct 中（这是 GORM 的设计取舍，不是 bug）
CreateInBatches 必须注意的参数顺序和返回值
函数签名是 db.CreateInBatches(value interface{}, batchSize int)，第一个参数必须是切片（[]User），不能传指针切片（*[]User）或单个 struct；batchSize 小于等于 0 会 panic，等于 1 就退化成逐条插入，失去意义。
返回值是 *gorm.DB，不是错误 —— 错误需通过 db.Error 检查。很多人写成 if err := db.CreateInBatches(...); err != nil，这是错的，编译都不过。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法：
result := db.CreateInBatches(users, 100); if result.Error != nil { /* handle */ } - 想获取影响行数？用
result.RowsAffected，它返回的是**总插入条数**，不是“最后一批”的数量 - 如果切片为空，
CreateInBatches不执行 SQL，RowsAffected为 0，Error为 nil —— 这是安全的，不用额外判空
批量插入时钩子（Callbacks）的行为差异
CreateInBatches 默认绕过大部分创建钩子：只有 BeforeCreate 和 AfterCreate 会在**整批开始前 / 结束后各执行一次**，而不是每条记录都执行。这对性能是好事，但容易引发逻辑错位。
典型场景：你依赖 BeforeCreate 自动生成 UUID 或时间戳，结果发现所有记录的 CreatedAt 时间完全一样，或者 UUID 重复了（因为没重入）。
- 解决办法一：在插入前手动处理切片：
for i := range users { users[i].ID = uuid.New(); users[i].CreatedAt = time.Now() } - 解决办法二：关闭钩子，用 GORM 的字段标签替代，例如
CreatedAt time.Time `gorm:"default:current_timestamp"`（依赖数据库支持） - 绝对不要在钩子里修改切片元素地址（比如
&users[i]），GORM 内部按值拷贝，改了也没用
比 CreateInBatches 更快的替代方案：原生 SQL + Exec
当插入量极大（如 > 10w 行）、结构简单、且不需要 GORM 的关联/钩子/软删除等特性时，手写批量 INSERT 并用 db.Exec 是最快的路径。GORM 的 CreateInBatches 仍要做反射、字段映射、SQL 拼接，有固定开销。
示例（MySQL）：db.Exec("INSERT INTO users(name, email) VALUES (?, ?), (?, ?), (?, ?)", "a", "a@b.c", "b", "b@b.c", "c", "c@b.c") —— 参数按顺序平铺，不嵌套。
- 优势：零反射、零结构体扫描、可控 SQL 格式、可复用 prepared statement
- 坑点：参数数量必须严格匹配
?个数，否则 panic；PostgreSQL 用$1, $2占位符，不能混用 - 安全边界：避免拼接用户输入进 SQL 字符串，只允许通过参数占位符传值
真正卡点不在语法，而在「什么时候该放弃 GORM」—— 如果你在 insert 前要校验 10 个业务规则、更新 3 张关联表、发消息、再记日志，那还是老实用 CreateInBatches；如果只是把 CSV 导进库，直接上原生 SQL 更干净。
