thinkphp事件不直接更新数据，仅在模型生命周期中触发钩子；真正更新由save/update执行，事件通过before_update等介入修改数据或抛异常拦截，但db::update和模型静态update不触发事件。
ThinkPHP 的事件机制本身不直接做数据更新，它只是在模型生命周期中触发钩子，真正执行更新的是 save 或 update 这类方法。想让事件“参与”更新，关键不是靠事件去写 SQL，而是把业务逻辑塞进事件里，再由事件驱动或干预后续的更新行为。
模型事件里能改哪些更新行为
ThinkPHP 模型支持 before_update、after_update 等事件，但它们不改变 SQL 执行本身，只提供一个介入时机：
-
before_update中可以修改即将保存的数据（比如补全update_time、过滤敏感字段、根据条件重写某个值），但不能阻止 save() 执行——除非抛异常 -
after_update适合发通知、写日志、清理缓存，不能反向修改已入库的数据 - 事件回调函数接收的是模型实例，所以能调用
$model->data()、$model->force()等方法，但不能直接调用Db::table()->update()——那会绕过事件体系，形成“事件里又触发事件”的嵌套风险
为什么 save() 更新有时不触发 before_update
常见原因是没走模型层更新流程：
- 用了
Db::name('user')->where(...)->update(...)：这是查询构造器直连数据库，完全跳过模型和事件 - 用了模型静态方法
User::where(...)->update(...)：同样不触发模型事件，只走底层 SQL - 模型实例没加载主键就调用
save()：例如$user = new User(); $user->name = 'x'; $user->save();，此时框架认为是新增，触发before_insert而非before_update - 调用
save()时传了空数组或没变的数据：ThinkPHP 默认只更新“有变化的字段”，若无变更，连事件都不触发（可加force()强制触发）
想让事件真正影响更新结果，得这样写
典型场景：用户编辑资料时，自动把邮箱转为小写，并拒绝更新已被软删除的记录。
protected static function init()
{
self::event('before_update', function ($model) {
// 强制转小写
$model->email = strtolower($model->email);
// 拦截已软删除的更新
if ($model->delete_time && !is_null($model->delete_time)) {
throw new Exception('该记录已被删除，不可更新');
}
});
}
- 必须用
self::event()静态注册，不能在构造函数或控制器里临时绑定 - 修改
$model属性会反映到最终 SQL，但不能改$model->id这类主键（会导致 UPDATE 条件错乱） - 抛异常是唯一可靠拦截方式；返回
false或静默修改字段不会中断流程
事件 + 批量更新容易掉坑的地方
saveAll() 会为每条数据逐个触发事件，但 update()（无论 Db 层还是模型静态）完全不触发：
- 用
User::saveAll($list)：每条记录都走完整模型生命周期，before_update会执行count($list)次 - 用
User::where('id', 'in', $ids)->update(['status' => 1])：零事件，哪怕你写了init()也无效 - 混合使用时注意事务边界：如果在
before_update里手动调了Db::transaction()，可能和外层saveAll()的事务冲突 - 大批量时事件开销明显：1000 条
saveAll()触发 1000 次事件回调，比纯update()慢 3–5 倍，别为了“统一入口”硬套事件
事件不是万能胶，它只在模型实例明确、生命周期可控的更新路径里生效。一旦切到查询构造器或静态批量操作，就得另配逻辑——这点很容易被忽略，尤其在从单条更新迁移到批量时。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
