Attribute::make()不支持运行时条件逻辑，因闭包执行早于关系加载，易触发N+1或报错；应改用get*Attribute()访问器，其具备完整模型上下文和relationLoaded()判断能力。
直接用 Attribute::make() 做条件逻辑，大概率会出错——它不支持运行时判断关系加载状态、不能安全访问未初始化属性，也不该承担业务分支职责。
什么时候不该用 Attribute 类写条件逻辑
当你需要根据 $this->type、$this->is_active 或关联模型状态（比如 $this->order->status）返回不同值时，Attribute::make() 就不合适。它的闭包执行时机早于模型关系加载，$this->relationLoaded('order') 在里面永远是 false，强行访问会触发 N+1 查询或报错。
- 闭包里调用
$this->user->name→ 懒加载一次，循环中就是 N+1 - 用
if ($this->profile)判断关系存在 → 总是null，因为关系没加载 - 在
Attribute里写DB::table()->where(...)->first()→ 违反“无副作用”原则，且无法被 eager load 优化
用 get*Attribute() 替代的实操要点
老派但可靠：把条件逻辑放进命名规范的访问器方法里，它天然拥有完整模型上下文和生命周期控制权。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 先检查关系是否已加载：
if ($this->relationLoaded('payment') && $this->payment) - 空字段用
?? ''或optional($this->profile)->bio防崩 - 数据库字段仍存原始值（如
state_code），访问器只负责读时转换 - 若需动态拼接多个关联字段，务必提前用
with(['profile', 'payment'])预载入
API 输出层该在哪做条件过滤
别在模型层塞太多 API 特定逻辑。模型访问器负责“数据语义”，API 资源（JsonResource）才管“输出形态”。比如同一模型对 v1 和 v2 接口返回不同字段：
- v1 需要
full_name，v2 改用display_name→ 在资源类里用when()控制：when($this->resource->hasV2(), fn () => ['display_name' => ...]) - 敏感字段（如
email）只给管理员 → 在资源的toArray()里加权限判断，而非在模型里硬编码Auth::user()?->can('view-email') - 想统一去掉
data包裹 → 在AppServiceProvider::boot()里调用JsonResource::withoutWrapping()
最易被忽略的是：条件逻辑的位置错位。模型不是万能胶，它不该替 API 层做权限裁剪、版本适配或前端展示格式决策；而 API 资源也不该反向侵入模型去查数据库。分清边界，比写出能跑的代码更难，也更重要。
