ThinkPHP事件不直接更新数据，仅在模型生命周期中触发钩子；真正更新由save/update执行，事件通过before_update等介入修改数据或抛异常拦截，但Db::update和模型静态update不触发事件。
ThinkPHP 的事件机制本身不直接做数据更新，它只是在模型生命周期中触发钩子，真正执行更新的是
或
这类方法。想让事件“参与”更新，关键不是靠事件去写 SQL，而是把业务逻辑塞进事件里，再由事件驱动或干预后续的更新行为。
模型事件里能改哪些更新行为
ThinkPHP 模型支持
、
等事件，但它们不改变 SQL 执行本身，只提供一个介入时机：
中可以修改即将保存的数据（比如补全
、过滤敏感字段、根据条件重写某个值），但不能阻止 save() 执行——除非抛异常
适合发通知、写日志、清理缓存，不能反向修改已入库的数据
事件回调函数接收的是模型实例，所以能调用
、
等方法，但不能直接调用
——那会绕过事件体系，形成“事件里又触发事件”的嵌套风险
为什么 save() 更新有时不触发 before_update
常见原因是没走模型层更新流程：
用了
：这是查询构造器直连数据库，完全跳过模型和事件
用了模型静态方法
：同样不触发模型事件，只走底层 SQL
模型实例没加载主键就调用
：例如
，此时框架认为是新增，触发
而非
调用
时传了空数组或没变的数据：ThinkPHP 默认只更新“有变化的字段”，若无变更，连事件都不触发（可加
强制触发）
想让事件真正影响更新结果，得这样写
典型场景：用户编辑资料时，自动把邮箱转为小写，并拒绝更新已被软删除的记录。
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
立即学习
“
PHP免费学习笔记（深入）
”；
必须用
静态注册，不能在构造函数或控制器里临时绑定
修改
属性会反映到最终 SQL，但不能改
这类主键（会导致 UPDATE 条件错乱）
抛异常是唯一可靠拦截方式；返回
或静默修改字段不会中断流程
事件 + 批量更新容易掉坑的地方
会为每条数据逐个触发事件，但
（无论 Db 层还是模型静态）完全不触发：
用
：每条记录都走完整模型生命周期，
会执行
次
用
：零事件，哪怕你写了
也无效
混合使用时注意事务边界：如果在
里手动调了
，可能和外层
的事务冲突
大批量时事件开销明显：1000 条
触发 1000 次事件回调，比纯
慢 3–5 倍，别为了“统一入口”硬套事件
事件不是万能胶，它只在模型实例明确、生命周期可控的更新路径里生效。一旦切到查询构造器或静态批量操作，就得另配逻辑——这点很容易被忽略，尤其在从单条更新迁移到批量时。
saveupdatebefore_updateafter_updatebefore_updateupdate_timeafter_update$model->data()$model->force()Db::table()->update()Db::name('user')->where(...)->update(...)User::where(...)->update(...)save()$user = new User(); $user->name = 'x'; $user->save();before_insertbefore_updatesave()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$model->idfalsesaveAll()update()User::saveAll($list)before_updatecount($list)User::where('id', 'in', $ids)->update(['status' => 1])init()before_updateDb::transaction()saveAll()saveAll()update()