批量插入应优先使用 insert() 方法，它绕过模型事件和验证、直接执行原生 SQL，效率最高；createMany() 和循环 save() 因实例化模型及触发钩子导致性能低下，且易内存溢出。
批量插入用 insert()，别用 createMany() 或循环 save()
直接调用模型的 insert() 方法是 Laravel 中最快、最节省内存的批量插入方式。它绕过模型事件、验证、强制类型转换和访问器/修改器，只做原始 SQL 的 INSERT INTO ... VALUES 操作。如果你只是把已清洗好的数组写进数据库，insert() 是唯一合理选择。
常见错误是误用 createMany()：它会为每条数据实例化一个模型对象、触发 creating 事件、执行 fill()、再逐条 save() —— 这本质是 N+1 插入，1000 条数据可能耗时数秒甚至报内存溢出。
-
insert()接收二维关联数组，键必须与数据库字段名完全一致（不走$fillable） - 不返回主键 ID（除非用
insertGetId()，但仅支持单条或自增主键） - 不会触发
creating/created等模型事件 - 字段值不做自动类型转换（比如
int字段传字符串也不会转）
DB::table('users')->insert([
['name' => 'Alice', 'email' => 'a@example.com', 'created_at' => now()],
['name' => 'Bob', 'email' => 'b@example.com', 'created_at' => now()],
]);
fill() 和 create() 是为单条「受控赋值」设计的
fill() 和 create() 的核心职责不是插入效率，而是安全赋值：校验 $fillable 白名单、跳过不可写字段、兼容访问器（如 setPasswordAttribute）、触发模型生命周期钩子。它们天然不适合批量场景。
例如你有一组前端提交的用户数据，需过滤字段、哈希密码、生成 UUID，这时应先用 collect($data)->map() 预处理成干净数组，再交给 insert()；而不是把原始请求数组丢给 createMany() —— 后者既慢，又可能因未设置 $fillable 导致静默丢数据。
-
create()内部调用new static($attributes)->save()，开销远高于裸 insert -
fill()不保存，只做属性赋值，仍需手动save() - 批量时若强依赖模型事件（如记录操作日志），应改用事务 + 显式触发，而非依赖
createMany()
大数量插入要分 chunk，避免 PDO 超限或内存崩掉
Laravel 的 insert() 默认不限制条数，但 MySQL 有 max_allowed_packet 上限（通常 4MB–64MB），PostgreSQL 也有协议层限制。一次性插 10 万条很容易触发 PDOException: SQLSTATE[HY000]: General error: 1390 Prepared statement contains too many placeholders。
- 用
collect($data)->chunk(1000)切分批次（1000 是较安全的默认值） - 每个 chunk 单独调用
insert()，并用DB::transaction()包裹保证原子性（可选） - 避免在 chunk 循环里调用
Model::unguard()—— 它是全局静态状态，多线程/并发下会污染其他请求 - 如果字段含 JSON 类型，注意部分旧版 MySQL 对 JSON 字符串长度敏感，chunk 大小需进一步下调
collect($users)->chunk(1000)->each(function ($chunk) {
DB::table('users')->insert($chunk->toArray());
});
想返回插入后的 ID？别硬扛，换方案
insertGetId() 只支持单条，且要求主键是自增整型。批量后想拿全部 ID，Laravel 原生不提供方案 —— 因为底层 SQL 标准就不支持一次 insert 返回多 ID。强行实现（如用 lastInsertId() 加计数推算）在高并发下极不可靠。
真实项目中，需要回传 ID 的批量场景，通常意味着业务逻辑本就不该“纯插入”。这时更稳妥的做法是：
- 先用
insert()批量写入，再用whereIn('email', [...])查出刚插入的记录（需有唯一索引字段） - 或改用 UUID 作为主键，插入前就生成好 ID 数组，插入后直接返回
- 或接受“异步通知”模式：插入完成后发消息，由下游服务查库补全
试图让批量插入同时承担“返回 ID”职责，往往暴露的是设计阶段没厘清数据流边界。
