应直接用查询构建器的delete()方法批量删除，而非遍历调用模型delete()；后者会加载模型、触发事件、无事务保障，易致数据不一致。
为什么 foreach($items->all() as $item) { $item->delete(); } 容易出错
这不是语法错误，而是逻辑陷阱：当 $items 是 Eloquent Collection 时，$items->all() 只是把模型实例转成 PHP 数组，但每个 $item 仍是完整模型对象——它仍会触发访问器、事件、软删除判断、关联加载等开销。更危险的是，若中间某次 delete() 抛异常（比如事务回滚、磁盘满、外键约束失败），前面已删的记录无法自动回滚，造成数据不一致。
批量删除必须用 delete() 而不是遍历调用
只要目标是物理或软删除一批记录，且不需要单条事件/回调，就该直接走查询构建器的 delete() 方法。它生成一条 SQL DELETE FROM ... WHERE ...，原子执行、无 PHP 层循环、不加载模型、不触发事件（除非你显式启用）。
- 正确：
Post::where('status', 'draft')->delete()（软删）或Post::where('status', 'draft')->forceDelete()（硬删，仅限启用了SoftDeletes的模型） - 错误：
Post::where('status', 'draft')->get()->each(fn($p) => $p->delete())—— 多余加载、N+1 风险、无事务保障 - 注意：
forceDelete()是模型实例方法，不能链式调用；Post::where(...)->forceDelete()会报错
需要事件或清理逻辑时，用事务 + 显式集合遍历
当你必须为每条记录执行附件删除、缓存清除、日志写入等操作时，遍历不可免，但必须加事务兜底，并控制加载粒度。
- 先用
pluck('id')或cursor()获取 ID 列表，避免全量模型加载 - 再用
whereIn('id', $ids)->withTrashed()->get()拿到带状态的模型集合（尤其涉及软删） - 包裹在
DB::transaction()中，确保全部成功或全部回滚 - 别在循环里调
save()或update()—— 这些会触发额外查询，改用updateMany()或原生 SQL 批量更新
外键级联与 nullOnDelete 的实际影响
循环删除父记录时，若子表没配 cascadeOnDelete() 或 nullOnDelete()，数据库会在第一条子记录冲突时就抛 Integrity constraint violation 异常，导致整个循环中断。这不是 Laravel 的问题，而是 MySQL 的默认行为。
- 查迁移文件，确认外键定义含
->onDelete('cascade')或->nullOnDelete() - 没配的话，要么补迁移，要么手动先删子表：
Child::where('parent_id', $parentId)->delete() -
cascadeOnDelete()删除快但不可逆；nullOnDelete()要求字段允许 NULL，否则迁移会失败
delete()；只有当每条记录的副作用不可合并时，才上循环，且必须配事务和 ID 预加载。
