ThinkPHP 无原生触发器机制，所谓“触发器”实为模型事件、Hook 钩子或手动回调的误称；滥用会导致隐式耦合、事务断裂与调试困难。
onAfterInsert、onBeforeUpdate）、Hook 钩子、或手动在控制器/服务中调用的回调逻辑的误称。滥用这类“伪触发器”极易导致隐式耦合、事务断裂、调试困难。
模型事件（onAfterInsert 等）为什么不能当数据库触发器用
ThinkPHP 模型的 onAfterInsert、onBeforeUpdate 等静态方法本质是框架级回调，它们：
- 不运行在数据库事务上下文中——如果模型操作回滚，这些回调已执行且不可逆
- 无法感知批量操作：比如
User::insertAll()不会逐条触发onAfterInsert - 只对模型方法生效，绕过
Db::table()->insert()或原生 SQL 就完全失效 - 若回调里再调用模型方法（如更新关联表），可能引发递归调用或 N+1
Hook 钩子在中间件之后才执行，时机不可控
通过 Hook::listen('user_login') 注册的钩子，其执行依赖于显式调用 Hook::exec()。但问题在于：
- 没人保证它一定在事务内——你得自己包裹
Db::transaction()，否则日志写成功、主表写失败，数据就撕裂了 - 多个 Hook 之间无执行顺序保障，
user_login和send_welcome_email谁先谁后？靠命名约定？不行 - Hook 无法被单元测试覆盖——它脱离请求生命周期，mock 成本高、断言难
- 一旦 Hook 抛异常，上层模型方法可能已返回成功，而后续动作卡住，形成半截状态
手动回调（如 save() 后立刻调 service::sync()）的三大硬伤
有些项目在控制器里写：$user->save(); UserService::syncToES($user);。这看似可控，实则埋雷：
- 违反单一职责：模型保存和搜索同步本该解耦，现在强绑在业务代码里，复用性归零
- 无法跨环境开关：测试环境不想跑 ES 同步？得加 if 判断，污染主流程
- 失败无兜底：ES 服务宕机，
syncToES()抛异常，整个用户注册流程就中断——而你本意只是“尽量同步”
正确做法是发消息（如 Redis List + Worker）或记录异步任务表，由独立进程消费。
立即学习“PHP免费学习笔记（深入）”；
真正需要“触发”逻辑时，优先走数据库事务 + 延迟队列
如果你确实要实现“用户创建后自动发通知、更新统计、同步第三方”，别碰模型事件和 Hook。直接用：
Db::transaction(function () use ($data) { $user = User::create($data); Queue::push(SendWelcomeEmail::class, ['user_id' => $user->id]); });- 或封装成领域服务：
UserDomainService::createWithSideEffects($data)，内部明确控制事务边界与异步分发 - 避免在模型
protected $dispatchesEvents = [...]（TP 不支持该写法）——这是 Laravel 的语法，TP 里硬套会报错
最易被忽略的一点：所有“触发”逻辑必须能重放。今天队列积压，明天补推，数据不能错乱——这就要求事件载荷只含 ID，所有读取都发生在线上执行时，而非回调闭包里捕获的瞬态对象。
