afterFind在每个AR实例构造并填充数据后立即执行，无论findOne()还是遍历均逐个触发；beforeSave的$insert参数由getIsNewRecord()决定，非主键存在与否，且必须返回true否则中断保存。
什么时候会触发 afterFind？别以为查出来就完事了
afterFind 不是“查询完成”的信号灯，而是每个 AR 实例被构造并填充数据后**立刻执行**的钩子——哪怕你只调用 findOne() 查一条，它也会触发一次；用 each() 或 batch() 遍历时，它会对**每一个模型实例**各触发一次。
常见错误现象：
– 在 afterFind 里改 $this->name，但后续 var_dump() 发现没变 → 忘了它不自动保存，只是读取后的处理时机
– 把耗时逻辑（如远程 API 调用）塞进去，结果列表页加载慢得离谱 → 它在每次实例化时同步执行，毫无延迟缓冲
- 典型使用场景：补全关联字段（如把
$this->category_id映射为$this->categoryName）、打日志、标记“已读取”状态 - 注意：
$this->_oldAttributes此时已同步为数据库值，但$this->getDirtyAttributes()返回空数组（还没改过） - 如果你重写了
init()，afterFind仍会在init()之后执行，顺序固定：constructor →init()→afterFind()
beforeSave 的 $insert 参数不是可选题，是必答题
这个布尔参数直接决定你是“新增”还是“更新”，但它**不是靠主键是否存在来判断的**，而是由 $model->getIsNewRecord() 决定——而后者又依赖于你是否显式设置了主键值，或是否刚用 new Model() 实例化且未调用 find()。
容易踩的坑：
– 手动设了 $model->id = 123 后调 save()，却还在 beforeSave 里当成新增处理 → 实际走的是 UPDATE，$insert 为 false
– 用 loadDefaultValues() 后没注意主键仍是 null，结果误判为新增 → 真实行为取决于底层是否生成了主键
- 必须返回
true，否则整个save()流程中断（连验证都不继续） - 推荐写法：先
if (!parent::beforeSave($insert)) return false;，再加业务逻辑 - 常见用途：统一设置
created_at/updated_at、过滤敏感字符、根据状态机校验合法性
afterFind 和 beforeSave 都不能替代事务边界
它们是模型层的生命周期钩子，**不是数据库事务的起点或终点**。比如你在 afterFind 里读了另一张表，在 beforeSave 里又写了它，这两次操作默认不在同一个事务里——除非你手动用 Yii::$app->db->transaction() 包裹整个流程。
性能影响很实在：
– afterFind 里做 N+1 查询（比如循环查每个用户的头像），列表页直接卡死
– beforeSave 里调外部 HTTP 接口，失败会导致主表写入失败，但外部服务可能已生效（缺乏幂等/回滚机制）
- 如果需要强一致性，优先考虑数据库约束、触发器，或在 Service 层统一封装事务
- 行为（Behavior）比直接重写方法更适合复用逻辑，尤其当多个模型都要自动维护时间戳时
-
afterFind里不要调$this->save()，极易引发无限循环（save → beforeSave → … → afterFind → save）
调试时怎么看事件到底有没有触发？
别靠 var_dump 或 die ——它们会打断生命周期，还可能污染响应头。正确姿势是用 Yii 自带的日志 + 断点：
- 在方法开头加
Yii::debug('enter afterFind', __METHOD__); - 配合
debug_toolbar查看「Log」面板，筛选debug级别消息 - 如果用了行为绑定（如
$model->on('afterFind', ...)），注意它和重写方法的执行顺序：重写的方法先执行，再触发 on 绑定的事件 - 检查是否被父类方法提前 return false：比如某个基类重写了
beforeSave却忘了调parent::beforeSave()，子类的逻辑就永远不跑了
最隐蔽的问题往往出在继承链上——你以为自己写了 beforeSave，其实被中间某层 silently 拦截了。打开 IDE 的 “Go to Implementation” 多点两下，比猜快得多。
