行为不是事件的替代品，而是可复用的组件扩展机制；它通过events()方法显式绑定事件处理器，内部可监听、触发、转发事件，但自身不自动产生事件，且生命周期由宿主对象管理。
Yii 行为（Behavior）和事件（Event）到底是什么关系
行为不是事件的替代品，也不是“高级事件”——它是一个可复用的组件扩展机制，内部可以监听、触发、转发事件，但本身不自动产生事件。常见误解是把 attachBehavior() 当成事件注册，其实它只是把一堆方法、属性、事件绑定逻辑打包挂载到目标对象上。
一个行为要响应外部事件，必须显式在 events() 方法里声明映射，例如：return [ActiveRecord::EVENT_AFTER_INSERT => 'afterInsertHandler']；否则即使写了 afterInsertHandler() 方法，也不会被调用。
- 行为的生命周期由宿主对象管理：
attach()时注册事件，detach()时自动解绑——这点比手动用Event::on()安全得多 - 行为中定义的方法不能直接当事件处理器用，除非在
events()里明确关联 - 多个行为监听同一事件时，执行顺序按
attachBehavior()调用先后，不可靠；需强序应改用事件总线或自定义调度逻辑
怎么写一个能自动监听模型事件的行为
以「记录操作日志」为例，行为需要监听 ActiveRecord::EVENT_AFTER_INSERT、EVENT_AFTER_UPDATE 等，但不能只靠硬编码字符串——得用常量，且确保宿主类已加载对应事件定义。
正确写法是继承 yii\base\Behavior，重写 events() 返回映射数组，并在对应 handler 方法里访问 $event->sender：
class AuditLogBehavior extends Behavior
{
public function events()
{
return [
ActiveRecord::EVENT_AFTER_INSERT => 'logInsert',
ActiveRecord::EVENT_AFTER_UPDATE => 'logUpdate',
ActiveRecord::EVENT_AFTER_DELETE => 'logDelete',
];
}
public function logInsert($event)
{
$model = $event->sender;
\Yii::info("Created: {$model->className()}#{$model->getPrimaryKey()}", 'audit');
}
}
- 别在
logInsert()里直接调$model->save()或其他可能再次触发事件的操作，容易死循环 -
$event->sender是原始模型实例，不是行为自身；行为内不能用$this代替模型上下文 - 如果行为要传额外参数（比如操作人 ID），得靠构造函数注入或从
\Yii::$app->user获取，不能依赖事件对象自带
为什么 Behavior::events() 里写的事件名没生效
90% 的失效是因为事件名拼写与目标类实际触发的不一致。比如你在行为里写 ActiveRecord::EVENT_AFTER_INSERT，但模型里实际调的是 $this->trigger('afterInsert')（少了个下划线），或者用了自定义事件名但没在模型中声明常量。
另一个常见原因是：行为挂载时机太晚。比如在控制器里先 $model->save()，再 $model->attachBehavior()，那之前触发的事件自然收不到。
- 检查目标类是否真触发了该事件：在模型对应方法里加
\Yii::debug("firing " . self::EVENT_AFTER_INSERT); - 确认行为已挂载：打印
get_class($model->getBehavior('audit'))看是否返回预期类名 - 避免在
init()或构造函数里依赖未初始化的$this->owner，此时行为还没 attach，$this->owner是 null
Behavior 和 Event::on() 全局监听混用会出什么问题
能混用，但风险高。比如你用 Event::on(Order::class, Order::EVENT_AFTER_PAY, ...) 做短信通知，又给某个 Order 实例挂了支付后发邮件的行为，两者都监听同一事件——这时谁先执行？无法保证，且行为 detach 后，全局监听还在内存里。
更麻烦的是调试：行为里的日志和全局监听的日志混在同一个 category 下，很难区分来源；一旦出现异常，栈里既有 behavior 方法又有 static callback，排查路径变长。
- 优先用行为封装垂直功能（如审计、缓存、软删除），用全局监听做跨域协作（如库存扣减 + 积分发放）
- 所有
Event::on()绑定，只要不是单次脚本，都得配对Event::off()，尤其在单元测试 tearDown 阶段 - 行为中若需触发新事件（比如「订单完成」后发
OrderEvent::EVENT_COMPLETED），必须确保该事件类已定义并继承yii\base\Event，否则数据丢失且无报错
trigger() 是由模型主动发起、被行为拦截、还是被全局监听捕获。漏掉任一环节，逻辑就断在看不见的地方。
