Laravel中动态属性需避免静态$appends依赖运行时上下文，应优先用append()或makeVisible()按需添加；注意hidden/casts冲突、调用时机及类型声明，确保序列化时正确输出。
模型里用 $appends 追加属性，但值是运行时才确定的
直接写在 $appends 数组里的属性，Laravel 会自动调用同名的 getXXXAttribute() 访问器。问题在于：如果这个值依赖请求上下文（比如当前用户权限、HTTP 头、或某次查询的临时状态），静态定义的访问器没法动态响应。
常见错误现象：$appends = ['is_favorited']，但 getIsFavoritedAttribute() 里想查 Auth::id()，结果 API 返回时总为空——因为序列化发生在模型实例化后、响应前，而中间件或控制器还没把用户信息塞进去，或者用了缓存导致访问器只执行一次。
- 真正需要的是“每次 toArray() 或 toJson() 时都重算”，不是靠访问器缓存值
- 避免在访问器里做耗时查询；如果必须查库，确保该查询已预加载或走缓存
- 如果属性只在特定接口需要，别全局追加，改用
makeVisible()按需暴露
makeVisible() 和 setVisible() 的区别与误用场景
makeVisible() 是追加一个或多个属性到当前实例的可见列表，不影响其他实例；setVisible() 是彻底重置整个可见字段白名单，慎用——它会把 $visible、$fillable 甚至默认字段都干掉。
使用场景：管理员看详情页要显示 raw_data 字段，但普通用户不能见。你不会在模型里写 $visible = ['id', 'name', 'raw_data']，而是：
if (auth()->user()->is_admin) {
$model->makeVisible(['raw_data']);
}
容易踩的坑：
-
makeVisible()必须在toArray()之前调用，链式调用无效（$model->makeVisible([...])->toArray()不生效，得分开写） - 对集合调用
makeVisible()会失败，得用each()或map()遍历每个模型 - 如果模型已转成数组再调
makeVisible()，完全没用——它只影响后续的序列化过程
用 append() 方法动态加字段，比改 $appends 更安全
append() 是模型实例方法，接受字符串或数组，内部会合并进当前实例的追加列表，不污染类定义，也不影响其他实例。
示例：给订单加一个 can_refund 字段，逻辑涉及当前时间、订单状态、用户角色：
$order->append(['can_refund'])->toArray();
对应要定义 getCanRefundAttribute()，但注意：
- 这个访问器会在每次
toArray()时执行，所以里面可以放心用request()、auth()或任何运行时上下文 - 如果字段值计算开销大，考虑在控制器里先算好，用
setAttribute()手动设值，再makeVisible()，绕过访问器 - 不要在
append()里传不存在的访问器名，否则序列化时报Undefined property
JSON 序列化时虚拟属性丢失？检查 casts 和 hidden 冲突
即使用了 append() 或 $appends，字段仍不出现在 JSON 里，大概率是被 $hidden 拦截了，或者类型转换出错。
典型错误：
-
$hidden = ['password', 'api_token']里不小心写了'is_favorited'，覆盖了追加逻辑 - 虚拟属性返回布尔值，但没在
$casts里声明，某些 Laravel 版本（尤其是 9.x 早期）会把它转成null - 用了
toArray()但前端收不到，其实是响应被中间件（如TransformsRequest）又过滤了一次
调试建议：在返回前 dump $model->getAttributes() 和 $model->getCastableAttributes()，确认字段是否真进了属性池。
动态属性不是魔法，它只是让访问器参与序列化流程；一旦漏掉调用时机、被隐藏规则拦截、或类型没对齐，就悄无声息地消失。最稳妥的方式永远是——先手动 setAttribute()，再 makeVisible()，而不是依赖自动追加。
