必须用 Query Builder 或原生 SQL 批量删除多态关联数据并包裹事务，因 $model->relation()->delete() 会逐条加载、触发事件、软删干扰、引发异常或死循环，且多态关系无外键约束。
直接删多态关联数据，不能只调用 $model->relation()->delete()，否则会触发 Eloquent 加载、软删除逻辑干扰、甚至死循环；必须绕过模型层，用 Query Builder 或原生 SQL 批量操作，并包裹事务。
为什么 delete() 在多态关系里容易出问题
多态关联（如 morphMany、morphToMany）没有外键约束，Eloquent 不知道该删谁、怎么删。调用 $post->comments()->delete() 看似合理，但实际会：
- 逐条加载每条
Comment实例，触发boot()中的deleting事件 —— 如果你在事件里又调了其他关联删除，可能递归或 N+1 - 若
Comment启用了SoftDeletes，delete()默认只会软删，而你本意可能是硬删（比如清理脏数据） - 如果
commentable_id指向已硬删除的记录，访问$comment->commentable会抛ModelNotFoundException，中断整个批量流程 - 不加事务时，删到一半失败，留下部分删除的中间状态，数据不一致
安全删 morphMany 关联（如 comments）
适用场景：删除某篇文章/视频下所有评论，且要硬删、跳过模型事件、防中断。
- 用
DB::table('comments')直接操作，不走Comment::class - WHERE 条件必须同时匹配
commentable_type和commentable_id，例如：where('commentable_type', 'App\Models\Post')->where('commentable_id', $postId) - 务必套
DB::transaction()，哪怕只删一条——防止部分成功 - 别写
Comment::where(...)->delete()，它会触发模型事件和访问器，可能再次触发morphTo加载
示例：
DB::transaction(function () use ($postId) {
DB::table('comments')
->where('commentable_type', 'App\Models\Post')
->where('commentable_id', $postId)
->delete();
});清理 morphToMany 中间表（如 taggables）
多态多对多（如 Tag 可打在 Post 或 Video 上）的中间表叫 taggables，结构含 taggable_type、taggable_id、tag_id。删关联不是删标签本身，而是删中间行。
- 用
DB::table('taggables')删除，不要调$post->tags()->detach()—— 它内部仍会先查再删，且可能触发观察者 - WHERE 必须严格限定
taggable_type（完整类名） +taggable_id，漏一个就会误删其他模型的标签 - 如果业务要求“只删某类标签”，额外加
where('tag_id', [...]) - 中间表无外键，删完不会级联影响
tags表，符合预期
示例（删掉某篇 Post 的所有标签绑定）：
DB::transaction(function () use ($postId) {
DB::table('taggables')
->where('taggable_type', 'App\Models\Post')
->where('taggable_id', $postId)
->delete();
});删完还要清空「挂空」的多态记录（脏数据）
这是最容易被忽略的一环：你删了 Post，但没删它的 comments，这些评论就成了指向不存在目标的脏数据。下次有人查 $comment->commentable 就报错或返回 null。
- 查脏数据必须用 SQL LEFT JOIN 或 NOT IN，不能依赖 Eloquent 的
withTrashed()—— 软删记录仍算“存在”，但业务上它已不可见 - 例如清理
comments表中所有指向已硬删Post的记录：SELECT * FROM comments c LEFT JOIN posts p ON c.commentable_type = 'App\Models\Post' AND c.commentable_id = p.id WHERE p.id IS NULL AND c.commentable_type = 'App\Models\Post' - 执行前确认
commentable_type + commentable_id有联合索引，否则大表会卡死 - 删脏数据也必须事务 + Query Builder，且建议分批（
limit 1000）避免锁表
真正健壮的清理，从来不是“删父模型时顺手删子”，而是定期用 SQL 扫描并剔除那些 commentable_type 存在但 commentable_id 已失效的行 —— 这才是多态关系长期稳定的底线。
