多态关联删除不会误删父级数据，误删源于子模型deleting事件中反向删父、未限定类型的whereDoesntHave查询或误用外键级联；正确做法是父模型控制生命周期并确保使用模型实例删除触发事件。
多态关联删除本身不会误删父级数据——误删通常源于对 delete() 调用位置、事件触发时机或外键约束的误解。真正危险的是在子模型的 deleting 事件里反向操作父模型，或在多态类型字段未受控时执行宽泛的批量删除。
多态关联 delete() 不会自动删父模型
Laravel 的多态关系（如 MorphTo）本身不提供级联删除能力。调用子模型的 delete()，只删该子记录，morph_type 和 morph_id 字段指向的父模型完全不受影响。
- 常见误操作：在
Comment::class（多态子模型）的deleting事件中写$comment->commentable->delete()—— 这会直接删掉文章或视频等父模型，且无提示 - 正确做法：除非业务明确要求（如“删除评论即下架整条动态”），否则不应在子模型事件中主动删父模型
- 若需联动，应由父模型控制生命周期，例如在
Post::deleting中统一清理所有comments()->where('commentable_type', Post::class)
whereDoesntHave + 多态类型字段组合筛选才安全
想删“没有被任何评论引用的文章”，不能只用 whereDoesntHave('comments')，因为该方法默认只查 MorphTo 关系中当前模型类对应的记录，而多态评论可能属于多个父类型（Post、Video、User）。必须显式限定类型：
Post::whereDoesntHave('comments', function ($q) { $q->where('commentable_type', Post::class); })->delete()- 漏掉
where('commentable_type', ...)会导致查询忽略其他类型的评论，误判为“无关联”，从而错误删除本应保留的Post - 若使用软删除，注意
whereDoesntHave默认不包含已软删除的评论；需加withTrashed()显式包含
onDelete('cascade') 对多态外键无效
数据库外键不支持多态字段的级联删除。你无法对 commentable_id 或 commentable_type 建立标准外键约束，因为外键必须指向唯一表的主键，而多态字段对应多张表。
- 迁移中写
$table->foreign('commentable_id')->references('id')->on('posts')->onDelete('cascade')是错的：它只约束到posts表，对videos或users的关联毫无作用，还可能因数据不一致导致插入失败 - 试图用触发器模拟多态级联极易出错，且绕过 Eloquent 事件，破坏审计与 Observer 逻辑
- 唯一可靠方案：在父模型
deleting事件或 Observer 中，按类型分别清理各关联子表，例如先删$post->comments()->delete()，再删$post->likes()->delete()
批量删除时 deleting 事件不触发是最大盲区
用 Post::whereIn('id', $ids)->delete() 删除多篇文章，Post::deleting 事件根本不会执行——这意味着你在 boot() 里写的子模型清理逻辑全部失效。
- 现象：文章被删了，但评论还在数据库里，变成孤儿数据
- 原因：查询构建器的
delete()是原生 SQL，不实例化模型，不走 Eloquent 生命周期 - 解法一（推荐）：改用集合遍历
Post::findMany($ids)->each->delete()，确保每个Post实例触发事件链 - 解法二（高性能场景）：手动补删，如
Comment::where('commentable_type', Post::class)->whereIn('commentable_id', $ids)->delete() - 注意：若父模型启用了软删除，
where()->delete()只更新deleted_at，此时需用forceDelete()或显式withTrashed()控制子模型行为
多态关联最易被忽略的点，是默认假设「删子就动父」或「外键能管住多态」——其实两者都不可靠。真正可控的只有你写在父模型事件里的那几行代码，以及每次执行前确认用的是模型实例删除还是裸 SQL 删除。
