Eloquent 的 delete() 默认不级联删除，需通过模型事件、外键约束或手动处理实现；软删除与数据库级级联互斥，多对多关系推荐 detach() 或 sync([]) 安全清理中间表。
直接用 delete() 不会级联删，除非显式配置
默认情况下，Laravel 的 Eloquent 模型调用 delete() 只删当前模型对应的数据行，关联表（比如 posts 下的 comments 或 tags）完全不受影响。这不是 bug，是设计使然——Eloquent 不自动猜测你的业务意图。
常见错误现象：$post->delete() 执行后，comments 表里对应记录还在，导致后续查询出现「孤儿数据」或外键约束冲突（如果数据库启用了 ON DELETE CASCADE 但 Laravel 层没同步处理）。
- 必须手动触发关联删除，或在模型中声明级联行为
- 数据库外键的
ON DELETE CASCADE和 Eloquent 的软删除（SoftDeletes）互不兼容，开启软删后该外键策略将失效 - 使用
forceDelete()时，仍不会自动删关联模型，除非你重写了逻辑
deleting 和 deleted 模型事件是可控入口
这是最常用、也最灵活的实现方式。在父模型被删除前/后，通过监听事件主动清理关联数据，避免误删或漏删。
class Post extends Model
{
protected static function boot()
{
parent::boot();
static::deleting(function ($post) {
$post->comments()->delete(); // 硬删评论
$post->tags()->detach(); // 解除多对多关系（不删 tags 表本身）
});
}
}
注意点：
-
deleting在事务内执行，若其中某步失败（如权限不足、DB 异常），整个删除会回滚 - 不要在
deleting里调用$post->comments->each->delete()，这会触发每个子模型的deleting事件，可能造成无限递归或 N+1 查询 - 如果关联是软删除（
SoftDeletes），要用$post->comments()->withTrashed()->delete()或forceDelete()显式处理
用 HasMany::onDelete('cascade') 需配合数据库外键
Laravel 10+ 支持在关系定义里声明数据库级级联，但仅限于生成迁移时使用，运行时无效：
public function comments()
{
return $this->hasMany(Comment::class)->onDelete('cascade');
}
这行代码本身不执行任何操作，它只在运行 php artisan migrate 时，让框架生成带 ON DELETE CASCADE 的外键语句。所以真正起作用的是数据库，不是 PHP。
- 必须确保迁移文件中实际生成了外键约束（检查 SQL 输出或数据库结构）
- MySQL 中，被引用字段（如
comments.post_id）必须是索引字段，否则外键创建失败 - SQLite 不支持
ON DELETE CASCADE的 ALTER TABLE，只能建表时指定；PostgreSQL 默认启用，但需确认DEFERRABLE设置是否影响事务顺序
多对多中间表用 detach() 或 sync([]) 更安全
对于 posts ↔ tags 这类通过中间表 post_tag 关联的情况，不能靠外键级联，因为中间表通常不设外键（或只设单向），且你不希望删掉 tags 表里的原始标签。
推荐写法：
-
$post->tags()->detach()：只删中间表记录，不碰tags表 -
$post->tags()->sync([])：效果同上，语义更清晰（“同步为空集合”） - 避免
$post->tags()->delete()—— 这会尝试删tags表主表数据，报错或误删
如果中间表有额外字段（如 sort_order），用 detach() 最稳妥；若需条件过滤再删，改用 wherePivot() + detach() 组合。
复杂点在于嵌套层级：比如删 Post → 删 Comments → 删每条评论的 Replies。这种场景下，事件监听比外键更可控，因为你能决定每层的删除顺序和条件，而数据库外键无法表达「只删三级以下回复」这类逻辑。
