getAttribute 抛出 AttributeNotFoundException 是因访问未定义的 Eloquent 属性（如不存在的访问器、字段或未加载关系），该异常继承自 RuntimeException，发生在 __get 阶段，早于模型事件，需重写 __get 方法全局拦截并在生产环境降级记录。
为什么 getAttribute 会抛出 Illuminate\Database\Eloquent\AttributeNotFoundException
这不是 Laravel 官方定义的“事件”，而是访问不存在的 Eloquent 属性时触发的异常。很多人搜“Attribute Error Events”，其实是想捕获模型上读取了未定义的 get* 访问器、不存在的字段或未加载的关系时的错误行为。
常见触发场景包括：$user->non_existent_accessor、$user->undefined_column、$user->relation_that_was_not_loaded->name。Laravel 默认直接抛出异常，不走事件系统。
- 该异常继承自
RuntimeException，不是ModelEvent类型，因此监听eloquent.*事件完全捕获不到 - 它发生在属性访问阶段（
__get），早于模型生命周期事件（如retrieved） - 在 API 响应中直接暴露会导致 500，且堆栈里看不到业务上下文
如何全局拦截 Eloquent 属性访问异常
最直接的方式是重写模型的 __get 方法，在抛出异常前做干预。但注意：不能简单 try/catch 后静默返回 null，否则会掩盖真实问题（比如拼写错误）。
推荐做法是在开发环境保留异常，在生产环境统一降级并记录上下文：
立即学习“PHP免费学习笔记（深入）”；
public function __get($key)
{
try {
return parent::__get($key);
} catch (\Illuminate\Database\Eloquent\AttributeNotFoundException $e) {
if (app()->environment('local')) {
throw $e;
}
\Log::warning('Eloquent attribute access failed', [
'model' => static::class,
'key' => $key,
'trace' => collect(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 5))
->map(fn($t) => $t['function'] ?? '')
->join(' → ')
]);
return null;
}
}
- 必须调用
parent::__get($key)，否则会绕过原始逻辑（如访问器、关系代理、强制转驼峰等） - 不要在
__get里做复杂逻辑（如 DB 查询），否则影响所有属性访问性能 - 如果项目用了 IDE Helper 或 PHPStan，这类拦截可能干扰类型推断，建议加
@phpstan-ignore-next-line
关系未加载导致的 “Undefined property” 怎么提前防御
这类错误实际是 Trying to get property 'xxx' of non-object，根源是 $model->relation 返回 null（关系未预加载或查询为空），而非 AttributeNotFoundException。
真正可靠的防御方式不是兜底异常，而是从调用侧控制：
- 用
optional($user->posts)->count()替代$user->posts->count() - 在查询时主动预加载：
User::with('posts')->find($id) - 对关键关系加断言：
if (! $user->relationLoaded('posts')) { throw new InvalidArgumentException(...); } - 避免在 Blade 中直写
{{ $user->posts->first()->title }}，改用{{ $user->posts->first()?->title }}（PHP 8.0+ 空安全操作符）
自定义访问器抛异常时怎么让错误更明确
如果你在 getFullNameAttribute 里手动 throw 了异常，那它不会被上面的 __get 拦截——因为访问器执行时已脱离 Eloquent 的属性查找流程，属于普通方法调用。
这时要靠 PHP 异常处理机制，而不是模型事件：
- 在访问器内用
throw new RuntimeException("Missing required field: {$this->first_name}")，比默认报错信息更具体 - 若需统一处理，可封装一个基类访问器工具：
safeAccess($this, 'first_name', 'last_name')，内部检查并抛出自定义异常 - 别在访问器里调用
$this->fresh()或 DB 查询，极易引发 N+1 和事务不一致
真正难调试的是嵌套访问器（A 访问 B，B 访问 C）出错时堆栈被截断。遇到这种情况，优先用 xdebug_break() 打断点，而不是依赖日志。
