批量操作应优先用 insert()、upsert() 和 DB::table() 直接写入，避免循环 create() 或 attach()；需注意字段顺序、唯一键约束、事务处理及响应精简，以保障性能与稳定性。
批量插入用 insert() 别用循环 create()
循环调用 create() 每次都走完整模型生命周期（验证、事件、访问器），100 条数据可能触发 100 次查询 + 100 次事件，性能断崖式下跌。
直接用 insert() 绕过 Eloquent，只做原始 SQL 批量写入：
DB::table('users')->insert([
['name' => 'Alice', 'email' => 'a@example.com'],
['name' => 'Bob', 'email' => 'b@example.com'],
]);
- 必须确保字段名和值顺序严格一致，
insert()不校验模型规则，错一个字段全批失败 - 不触发
creating/created等模型事件，如有日志、缓存更新等逻辑，得手动补 - 自增 ID 不会返回，如果后续依赖新 ID（比如关联插入），得改用
insertGetId()+DB::select('SELECT LAST_INSERT_ID()')配合事务
大批量更新优先用 upsert()（Laravel 9+）
想根据唯一键（如 email）存在则更新、不存在则插入？别手写 firstOrCreate() 循环 —— 单条查 + 单条写，IO 成倍放大。
upsert() 是数据库原生支持的原子操作，MySQL 用 INSERT ... ON DUPLICATE KEY UPDATE，PostgreSQL 用 ON CONFLICT：
User::upsert(
[
['email' => 'a@example.com', 'name' => 'Alice', 'updated_at' => now()],
['email' => 'b@example.com', 'name' => 'Bob', 'updated_at' => now()],
],
['email'], // 唯一键
['name', 'updated_at'] // 冲突时更新这些字段
);
- 第二个参数（唯一列）必须是数据库里已建 UNIQUE 或 PRIMARY KEY 的字段，否则报错或行为未定义
- 第三个参数不能包含主键（如
id），否则 MySQL 报Column 'id' cannot be null - Laravel 8 及以下没
upsert()，得手动写原生语句或升级
关联批量操作避免 N+1 和内存溢出
给 1000 个用户批量分配角色？别在循环里调 $user->roles()->attach($roleId) —— 生成 1000 条 INSERT，还可能爆内存（每个模型实例带关系加载器）。
- 用
DB::table()直接写中间表：DB::table('model_has_roles')->insert($batchData) - 如果必须走模型，先取所有用户 ID，再一次性同步：
Role::find($roleId)->users()->sync($userIds) - 超过 5000 行建议分块（
collect($data)->chunk(1000)），不然单次 SQL 超长或 PDO 参数超限
注意：中间表字段名默认是 model_id / role_id，如果自定义了 foreign_key，sync() 仍按约定走，别指望它自动适配。
API 响应里别直接返回批量操作结果集
用户发一个批量创建请求，你返回全部新建的模型数组？1000 条数据序列化后响应体可能到 2MB+，前端解析卡顿，移动端直接失败。
- 只返回关键摘要：
['count' => 1000, 'failed' => 3, 'errors' => [...]] - 失败详情用异步任务落库，提供
job_id让前端轮询或 WebSocket 推送 - 真要返回数据，加
limit=100参数并明确告知“仅示例”，避免被当默认行为滥用
批量操作的本质是「吞吐优先」，不是「交互友好」。接口设计得向这个前提低头，而不是硬塞 CRUD 习惯进去。
