软级联删除需手动实现，Laravel不原生支持；应通过deleting事件判断isForceDeleting()后调用关联模型delete()，避免forceDelete()或withTrashed()误用，注意关联查询要适配softDeletes。
软级联删除（Soft Cascade）不是 Laravel Eloquent 原生支持的功能——它不会自动对关联模型调用 delete() 或 forceDelete()，更不会在软删除（softDeletes）场景下递归地把关联记录也“标记为已删除”。必须手动干预，否则关联数据会残留，破坏业务一致性。
为什么 withTrashed() 和 forceDelete() 不能解决软级联问题
很多人误以为开启软删除后，只要父模型 forceDelete()，子模型就会跟着物理删除；或者用 withTrashed() 查询就能“等效级联”。其实这两者完全不相关：
-
withTrashed()只是查询时包含已软删除的记录，不影响删除行为本身 -
forceDelete()确实能物理删掉当前模型，但默认**不会触发任何关联模型的删除逻辑**（无论软硬） - Eloquent 的
onDelete('cascade')是数据库外键约束，只对物理删除生效，且与软删除冲突（软删不走DELETE语句）
用 deleting 和 deleted 事件手动实现软级联
最可控、兼容性最好的方式是在模型事件中显式处理关联软删除。注意必须区分“正在软删”和“正在硬删”，避免误删：
- 监听
deleting事件（删除前），检查是否是软删除：$model->isForceDeleting() === false - 仅在此条件下，对关联模型调用
delete()（触发它们自己的软删除） - 避免在
deleted事件里操作，因为此时主模型已不可靠（如关系已断开、属性可能被清空） - 若关联模型未启用
softDeletes，需提前确认是否允许软删，否则会报错或静默失败
示例（Post 软删时同步软删所有 Comments）：
立即学习“PHP免费学习笔记（深入）”；
// 在 Post 模型中
protected static function boot()
{
parent::boot();
static::deleting(function ($post) {
if (! $post->isForceDeleting()) {
$post->comments()->delete(); // 自动调用每个 Comment 的 delete()
}
});
}
关联关系定义要支持软删除查询与操作
如果子模型用了 softDeletes，它的关联方法必须显式包含 withTrashed()，否则 $post->comments 默认查不到已软删的记录，导致级联逻辑漏判或重复删除：
- 定义关联时加
->withTrashed()（适用于需要看到历史软删记录的场景） - 但级联删除逻辑中，应直接用
$post->comments()（即带条件的 Builder），而非$post->comments（已加载的 Collection），否则可能操作过期数据 - 如果子模型关联方法没加
withTrashed()，而你又在事件里调用$post->comments()->delete()，Eloquent 仍会正确执行（因为 Builder 不受模型实例状态影响）
推荐写法（Comment 模型已 use SoftDeletes）：
// Comment.php 关联反向定义（可选，便于查询）
public function post()
{
return $this->belongsTo(Post::class)->withTrashed();
}
第三方包 ksmiling/eloquent-soft-cascade 的实际限制
这个包确实能简化配置，但要注意它底层仍是基于模型事件，因此存在几个关键盲区：
- 不自动处理“多层嵌套”（如 Post → Comment → Like），需逐级手动声明
SoftCascadeable - 若关联模型的软删除字段名不是默认的
deleted_at，包无法自动识别，会跳过处理 - 当使用
whereHas()+delete()批量操作时，事件不触发，软级联完全失效 - 升级 Laravel 版本后常出现
Call to undefined method ... onDelete()错误，因包依赖旧版 Eloquent 内部方法
结论：适合简单一对一/一对多场景快速起步，但线上项目涉及数据一致性要求时，手写事件更透明、更可控。
真正麻烦的从来不是“怎么让子记录也软删”，而是“哪些子记录该删、哪些不该删、删到第几层、并发时会不会删重、事务回滚后状态是否一致”——这些没法靠一个 trait 或事件自动兜底，得结合业务规则一行行写清楚。
