Computed Attributes 是运行时动态计算的值，非数据库字段，不应序列化；$casts 仅处理类型转换，$appends 只控制输出开关，不提供计算逻辑；应使用命名规范的访问器（如 getFullNameAttribute）实现，确保 ORM 兼容与安全性。
Computed Attributes 是什么，为什么不能直接用 $casts 或 $appends
Computed Attributes 不是数据库字段，也不该被序列化进 JSON——它只是运行时动态计算的值。Laravel 的 $casts 只处理类型转换（比如把字符串转成 Carbon），$appends 虽然能加字段到 toArray() 和 JSON 输出，但它本身不提供计算逻辑，只是个“挂载开关”。真要实现“每次访问都重新算”，得靠访问器（Accessors）。
用 get{Attribute}Attribute 定义计算属性最稳妥
这是 Laravel 官方支持、ORM 层原生兼容的方式。Eloquent 会自动识别命名规范的访问器，并在模型实例上以属性形式暴露，同时保证它不出现在 SQL 查询里、不被批量赋值、不进数据库迁移。
- 函数名必须严格匹配 PascalCase：比如想暴露
full_name，就写getFullNameAttribute() - 访问器内可安全调用其他属性或关系：
$this->first_name . ' ' . $this->last_name，或$this->posts->count() - 如果计算开销大（比如要查关联表聚合），建议加缓存层或改用显式方法（如
getTotalRevenue()），避免误触导致 N+1 - 注意：访问器返回值不会被
$casts处理，如需类型保障，得手动 cast，例如(int) $this->price * $this->quantity
什么时候该用 $appends + 访问器，什么时候不该
$appends 只控制“是否随 toArray() / JSON 自动包含”，和计算逻辑无关。它容易被滥用成“假装有字段”的捷径，但代价明显：
- 若只在 Blade 模板里用，根本不用加
$appends——直接$user->full_name就行 - 若加了
$appends = ['full_name']，但忘了定义getFullNameAttribute()，运行时报错Call to undefined method ...getFullNameAttribute() - API 返回时若大量模型带
$appends，且访问器里含 N+1 查询，性能会断崖下跌 - 测试时容易漏掉：访问器逻辑没覆盖边界情况（比如
first_name为 null），JSON 输出就出现 "null " 这种拼接结果
别用 __get() 或 __set() 拦截实现计算属性
有人想“统一管理”，在模型里重写 __get() 来拦截未定义属性并计算。这看似灵活，实则破坏 Eloquent 行为一致性：
立即学习“PHP免费学习笔记（深入）”；
-
isset($user->full_name)返回 false，哪怕访问器存在，因为__get()不影响 isset - 序列化（serialize）、队列任务、Livewire 绑定等场景下，
__get()可能不触发，导致数据不一致 - IDE 和 PHPStan 等静态分析工具完全无法识别这种动态属性，补全和类型提示失效
- Laravel 自身的
getAttribute()、getOriginal()、isDirty()全部绕过你的逻辑，调试时极易迷惑
真正需要动态字段映射的场景（比如多语言字段），应该用单独的服务类或资源类（Resource），而不是在模型里搞魔术方法。
