Eloquent 没有“属性延迟事件”机制，模型事件仅在 save() 等持久化操作时触发；setAttribute() 仅修改内存值，不触发事件；应使用 saved 事件配合标记字段和队列实现可靠延迟逻辑。
PHP 中 Eloquent 没有原生的 Deferred Events 或 “属性延迟事件” 机制 —— 这个概念在 Laravel 官方文档和核心代码里根本不存在。所谓“Eloquent Attribute Deferred Events”，是部分开发者对某些行为的误读或自行封装的术语，容易引发配置错误、事件丢失或竞态问题。
为什么 setAttribute() 不会触发模型事件
Laravel 的模型事件（如 saving、updating）只在调用 save()、update()、create() 等持久化方法时触发。单纯调用 $model->name = 'xxx' 或 $model->setAttribute('name', 'xxx') 只是修改内存中的属性值，不经过事件调度器。
- 这是设计使然：避免每次赋值都开销事件循环
- 如果你发现“设了属性但监听器没执行”，大概率是因为漏掉了
save() -
getAttribute()和setAttribute()是底层访问器，不参与事件生命周期
想“延迟触发事件”？用 saved + 标记字段更可靠
真正接近“延迟处理”的常见做法，是在 saved 事件中检查某个标记字段（比如 pending_action），再分发后续逻辑。它不依赖虚构的“属性级事件”，而是利用已知、稳定、可测试的生命周期钩子。
// 在模型中
protected static function booted()
{
static::saved(function ($model) {
if ($model->isDirty('pending_action') && $model->pending_action === 'send_notification') {
// 延迟执行动作（可配合队列）
SendNotificationJob::dispatch($model);
$model->pending_action = null;
$model->saveQuietly(); // 避免再次触发 saved
}
});
}
- 不要用
updating判断字段变化 ——isDirty()在saved里才准确反映本次更新内容 - 用
saveQuietly()避免递归触发事件 - 标记字段建议加数据库索引（如需批量扫描）
getAttributeValue() 和访问器不是事件触发点
有人试图在 getXXXAttribute() 或 getAttributeValue() 里写业务逻辑甚至 dispatch 事件，这属于严重误用：
立即学习“PHP免费学习笔记（深入）”；
- 访问器可能被多次调用（Blade 渲染、API 转换、日志打印），导致事件重复分发
- 访问器执行时机不可控（比如序列化时也会触发），无法保证数据一致性
- 违反单一职责：访问器只负责格式转换，不负责副作用
- 若该逻辑依赖数据库状态，还可能因缓存或延迟加载导致读到旧值
真正需要延迟执行的副作用，应该明确收敛到模型生命周期事件（saving/saved）、队列任务或应用服务层，而不是塞进属性访问过程里。Laravel 的事件系统本身不支持“为某个属性赋值就自动触发某事件”这种粒度——这不是缺陷，而是刻意为之的约束。
