最安全可靠的方式是使用 laravel 官方提供的 withoutevents()，它临时挂起模型事件系统，执行后自动恢复，不污染全局状态，且支持嵌套调用。
直接用 withoutEvents() 最安全可靠
绝大多数场景下，你不需要自己造轮子或动底层事件分发器——Laravel 官方提供的 withoutEvents() 就是为此而生的。它不是“绕过”事件，而是临时挂起整个模型事件系统，执行完闭包后自动恢复，不会污染全局状态。
- 只对闭包内执行的 Eloquent 操作生效，不影响外部其他请求或队列任务
- 支持嵌套调用，内部再套一层
withoutEvents()也没问题 - 不触发
saving、saved、updating、updated等任何事件，包括 Observer 中对应的方法 - 注意：它不阻止模型的
boot()或访问器/修改器（accessors/mutators）执行，那些仍会运行
示例：
$user = \App\Models\User::withoutEvents(function () {
$u = \App\Models\User::find(1);
$u->name = 'Alice';
$u->save(); // ✅ 不触发任何模型事件
return $u;
});
用 update() 或 insert() 是最轻量的替代方案
如果你只是想改几条字段、插一条记录，且完全不需要模型生命周期（比如不依赖 creating 中生成 UUID、不走自定义 setPasswordAttribute），那直接跳过模型实例，走查询构造器是最干脆的做法。
-
update()和insert()是静态方法，不实例化模型，自然不走事件系统 - 省去模型加载、属性赋值、变更检测等开销，性能略高（尤其批量操作时）
- ⚠️ 缺点：丢失模型层逻辑——比如软删除字段不会自动填充、时间戳不会更新（除非手动写
updated_at）、casts不生效、fillable校验也跳过 - 不能用于需要触发
static::created()后续处理的场景（比如要立刻发通知但又不想进事务）
示例：
\App\Models\User::where('id', 1)->update(['name' => 'Bob']); // ✅ 无事件，但也不会自动更新 updated_at（除非显式传入）
别手写 disableEvents() ——它不是 Laravel 原生方法
网上有些代码片段会教你调用 User::disableEvents()，但这是个常见误解。Laravel 核心从未提供 disableEvents() / enableEvents() 这两个静态方法，它们既不在文档里，也不在源码中。强行使用会导致 BadMethodCallException。
- 有人基于
unsetEventDispatcher()自己封装，但容易出错：比如忘记恢复分发器，导致后续所有请求的模型事件永久失效 - 更隐蔽的坑：在队列任务或并发请求中，这种全局开关可能互相干扰
- 如果你真需要细粒度控制（比如只禁用某类事件），应该用
Event::fake([UserSaved::class])（测试专用）或在监听器里加条件判断，而不是动分发器本身
事务里事件已触发 ≠ 数据已提交，回滚后监听器不撤销
这是最容易被忽略的语义陷阱：哪怕你在 DB::transaction() 里调用 save()，created 或 saved 事件也会在 SQL 执行后立刻触发，**早于事务 commit**。一旦事务最终 rollback，数据库数据消失，但事件监听器（比如发邮件、写日志、调第三方 API）已经执行完了。
- 后果很实际：用户没注册成功，但激活邮件却发出去了；订单没落库，但库存扣减已完成
-
withoutEvents()不能解决这个问题——它只是不触发事件，但如果你本意是“等事务成功再触发”，那得换思路：把事件调度延迟到事务外，或改用队列任务 +afterCommit()（Laravel 9+ 支持） - 简单补救：在监听器里手动检查数据库是否真实存在该记录，但这属于事后兜底，不推荐作为主逻辑
所以真正关键的不是“怎么关事件”，而是“事件该在什么时机语义上成立”。这点比语法技巧重要得多。
