本文解析 laravel 中 observer 的事件触发边界：当父模型通过批量查询（如 `->delete()`）删除子模型时，不会触发子模型的 observer 事件；需显式逐个调用 `delete()` 方法才能激活对应 observer 的 `deleted` 回调。
在 laravel 应用中，Observer 是实现模型生命周期解耦的重要机制。但其行为并非“无条件递归生效”——关键在于事件是否被真正分发。以典型的三层关系为例（Parent → Child → Grandchild），即使已为 Child 和 Grandchild 正确注册了 Observer，若 ParentObserver 中使用 $parent->children()->delete() 删除子记录，该操作将直接执行 sql DELETE 语句，绕过 Eloquent 模型实例化流程，因此 不会触发 Child::deleted 事件，自然也不会调用 ChildObserver::deleted()。
这意味着：
✅ ChildObserver::deleted() 在手动调用 $child->delete() 时正常执行（因完整走 Eloquent 生命周期）；
❌ ParentObserver::delete() 中的 $parent->children()->delete() 属于批量删除（mass delete），不实例化 Child 模型，故 ChildObserver 完全静默。
正确做法：显式触发子模型生命周期
要确保子模型 Observer 被调用，必须让每个子模型经历完整的 Eloquent 删除流程。推荐以下两种写法（均适用于 Laravel 6+）：
✅ 方案一：使用 get()->each()（兼容性最佳）
class ParentObserver { public function deleted(Parent $parent) { $parent->children() ->get() // 获取所有 Child 实例（内存敏感场景慎用） ->each(fn (Child $child) => $child->delete()); } }✅ 方案二：使用 cursor() + 高阶消息（推荐，内存友好）
Laravel 6 引入了 cursor() 方法，支持游标式遍历，避免一次性加载全部数据到内存：
class ParentObserver { public function deleted(Parent $parent) { $parent->children() ->cursor() // 返回 LazyCollection，按需加载 ->each->delete(); // 高阶消息：等价于 each(fn ($c) => $c->delete()) } }? 提示：cursor() 在大数据量场景下显著降低内存占用，是 Laravel 6+ 处理关联删除的首选方式。
注意事项与最佳实践
- 区分 delete() 与 forceDelete()：forceDelete() 同样跳过 Observer，仅用于软删除模型的强制清除。
- 事务一致性：上述逐个删除操作默认不在事务内。若需原子性，应包裹在 DB::transaction() 中：
DB::transaction(function () use ($parent) { $parent->children()->cursor()->each->delete(); }); - 性能权衡：cursor()->each->delete() 比批量删除稍慢（N+1 查询），但换来的是可预测的事件链。若性能成为瓶颈，可考虑在 ChildObserver::deleted() 中补充清理逻辑，或改用数据库级级联删除（需谨慎评估业务约束）。
- 验证 Observer 注册：确保在 AppServiceProvider::boot() 中正确绑定：
Parent::observe(ParentObserver::class); Child::observe(ChildObserver::class);
总之，Laravel Observer 的触发严格依赖模型实例的生命周期方法调用。理解“批量操作不触发事件”这一核心原则，是设计健壮、可维护模型事件链的关键。