TP8的model.before_write是新增和更新共用的统一前置钩子，而TP6的creating仅在insert时触发；TP8的after_*事件在事务commit前执行，TP6默认在commit后。
TP8 的 model.before_write 和 TP6 的 creating 不是一回事
TP8 彻底弃用了 Laravel 风格的 creating/created 等事件名，也不识别模型内 $dispatchesEvents 声明。所有模型生命周期事件统一以 model. 为前缀，且必须显式监听——比如 model.before_write 是新增和更新共用的统一前置钩子，而 TP6 的 creating 仅在 insert 场景触发，语义更窄、注册方式也不同（TP6 支持模型静态方法 observe() 或 event() 动态绑定）。
TP8 的 after_* 事件在事务 commit 前执行，TP6 默认在 commit 后
这是最易踩坑的差异点：TP8 的 model.after_insert、model.after_update 均在数据写入完成但事务尚未提交时触发；而 TP6 在默认配置下（非手动事务）会等 save() 返回后才真正 commit，所以它的 created 事件能稳定拿到 $model->id，且队列任务可立即查到新记录。
- TP8 中直接在
after_insert里dispatch()队列，消费端大概率查不到刚插入的数据 - TP6 下同位置 dispatch 通常没问题（除非你主动套了
Db::transaction()） - TP8 若需可靠读取新数据，必须监听
DbTransactionCommitted事件，或改用ResponseSent钩子
批量操作在 TP8 和 TP6 中都不触发模型事件，但原因不同
TP6 和 TP8 都明确约定：只有调用模型实例方法（如 $user->save()、$user->delete()）才会触发事件；User::where()->update() 这类静态批量操作走的是 Db 查询构造器，绕过模型层。
- TP6 中，
update()静态方法内部仍会尝试构建模型实例，部分场景下可能误触发updating（不稳定，不推荐依赖） - TP8 彻底剥离，
User::where()->update()完全不创建模型实例，事件监听器绝对收不到任何信号 - 若业务强依赖批量变更事件，必须拆成循环单条
save()，或改用 Db 事件（如db.query）配合 SQL 解析
TP8 要求监听必须在初始化阶段完成，TP6 允许运行时动态注册
TP8 的事件系统基于容器绑定 + 总线调度，所有 Event::trigger() 调用都依赖启动时已加载的 bind 和 listen 配置。你在控制器里写 event()->listen('model.before_write', [...]) 是无效的——框架不会重新扫描监听器。
立即学习“PHP免费学习笔记（深入）”；
- TP6 中
event('model.before_insert', [...])可在任意位置调用，虽不推荐但能生效 - TP8 必须把监听逻辑写进
app/event.php的listen数组，或在AppService::boot()中用Event::listen()显式注册（仍需确保早于模型首次使用） - 漏掉这一步，日志里不会报错，事件就静默消失——连 debug 日志都看不到触发痕迹
关键差异其实就卡在两处：一是事件命名与注册机制彻底重构，二是事务时机不可逆地前移。如果你从 TP6 升级过来，别只改事件名，先检查所有 after_* 里的 DB 查询和队列分发逻辑，它们大概率已在 TP8 下失效。
