模型事件仅在单条Eloquent操作（如save、create）时触发，DB::table或upsert等批量操作不触发；creating在插入前执行（无ID），created在插入后执行（有ID）；监听器须在boot()中注册；软删除触发deleting/deleted，物理删除需forceDeleted。
模型事件触发时机不一致？先确认是否用了 save() 而非批量操作
模型事件（如 creating、saved）只在单条模型实例调用 save()、create()、update() 等方法时触发，DB::table() 或 Model::upsert()、insert() 这类绕过 Eloquent 的操作完全不会触发任何模型事件。
常见错误现象：写好了 static::saved() 回调，但数据插入后钩子没执行——大概率是用了 DB::insert() 或事务里直接写了原生 SQL。
- 使用场景：需要自动填充字段、记录日志、触发通知等依赖模型生命周期的操作
- 如果必须批量写入且要事件，改用
Model::insert()+ 循环new Model()->fill()->save()，或手动在循环里调用fireModelEvent() -
upsert()在 Laravel 9+ 支持，但它也不触发事件，哪怕你传了$model->exists = true
creating 和 created 的关键区别：数据库是否已写入
creating 在 INSERT 语句执行前触发，此时模型还没主键（$model->id === null），适合做属性预设、权限校验或拒绝保存；created 则在 INSERT 完成后触发，主键已存在，能安全关联其他表或分发事件。
容易踩的坑：在 creating 里试图读取 $model->id 或调用 $model->fresh()，结果是 null 或报错。
- 参数差异：
creating回调接收的是“即将入库”的模型，created接收的是“刚入库成功”的模型 - 性能影响：在
creating中做耗时操作（比如远程 API 请求）会阻塞写入；created同理，但至少不影响当前事务的原子性 - 示例：
static::creating(fn ($model) => $model->uuid = Str::uuid()); // ✅ 可行<br>static::created(fn ($model) => Cache::forget("user_{$model->id}")); // ✅ 可行
监听器注册位置不对？别在 boot() 外写静态回调
模型事件监听器必须在模型的 boot() 方法中注册，否则可能因类加载顺序问题漏掉事件。写在构造函数、服务提供者或控制器里基本无效。
常见错误现象：事件回调定义了，但完全不执行；或者只在 Tinker 里生效，Web 请求下失效——往往是注册时机太晚或重复注册导致覆盖。
- 正确写法：
protected static function boot()<br>{<br> parent::boot();<br> static::updating(fn ($model) => $model->updated_at = now());<br>} - 不要在
booted()或模型外部文件里注册，Laravel 不会自动发现这些回调 - 多个监听器按注册顺序执行，但
creating中return false会终止后续所有监听器和保存动作
软删除模型的事件名不是 deleted，而是 deleting/deleted，但行为不同
软删除触发的是 deleting（逻辑删除前）、deleted（逻辑删除后），而不是 forceDeleted——后者只在调用 forceDelete() 时才触发，对应真实 DELETE SQL。
容易被忽略的地方：以为 deleted 表示记录从数据库消失了，其实只是 deleted_at 被设值，记录还在。真要清理物理数据，得监听 forceDeleted 并确保调用的是 forceDelete()。
- 使用场景：
deleting适合阻止敏感数据被逻辑删除（比如检查关联订单）；forceDeleted才适合清理附件、释放第三方资源 - 兼容性注意：Laravel 8+ 对
forceDeleted的支持更稳定，老版本可能需手动监听eloquent.forceDeleted: ModelName事件 -
restoring和restored是软删除恢复时的对应事件，别和updating混用
事情说清了就结束。模型事件本质是 Eloquent 的拦截机制，它不介入查询构建、不参与批量操作、也不保证跨进程可见——别把它当消息队列用。
