hidden 优先级高于 append，字段若同时在 $hidden 和 $appends 中则不会出现在 JSON 中；$casts 与访问器同名会导致类型冲突；动态控制应使用 makeVisible() 或 API 资源类，而非修改 $appends。
hidden 和 append 同时存在时，Laravel 怎么决定字段是否出现在 JSON 里
结论很直接：hidden 优先级高于 append。哪怕你在 $appends 里写了 full_name，只要它同时在 $hidden 里，最终 JSON 输出里就看不到。
这不是 bug，是 Laravel 序列化逻辑的明确行为：先按 $hidden / $visible 过滤原始属性，再把 $appends 的访问器结果“补”进去——但补的前提是该字段没被隐藏。
-
$hidden = ['password', 'full_name']+$appends = ['full_name']→full_name不会出现 -
$visible = ['id', 'name']+$appends = ['full_name']→ 只有id、name、full_name出现，其他全被过滤 - 没设
$hidden或$visible时，$appends才能正常生效
Laravel 9+ 中 $casts 和 $appends 字段类型不一致导致 JSON 输出异常
常见现象：你定义了 getFullNameAttribute()，返回字符串，但模型里 $casts = ['full_name' => 'array'] ——结果 JSON 里 full_name 变成 null 或空数组。
原因在于 Laravel 序列化时会先走 $casts 转换逻辑，再调用访问器；如果字段名和访问器同名，且被 $casts 声明过，访问器可能被绕过或类型冲突。
- 避免用和访问器同名的字段名写进
$casts - 如果真需要 cast 后再加工，改用不同名访问器，比如
getFormattedNameAttribute()，并加到$appends - 检查
toArray()输出，确认字段值是否符合预期，别只看 API 响应——有时是前端缓存或中间件干扰
想动态控制 append 字段，但用 $appends 静态声明做不到
$appends 是类属性，写死就全局生效，没法按请求、用户权限或条件开关。硬编码一堆条件判断在访问器里（比如 return auth()->user()->is_admin ? ... : null）会导致 JSON 里出现 "full_name": null，污染结构。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 改用
makeVisible()或makeHidden()动态操作：$user->makeVisible(['full_name'])->toArray() - 更干净的做法是在资源类（
UserResource）里控制：public function toArray($request) { return ['id' => $this->id] + ($request->user()->isAdmin() ? ['full_name' => $this->full_name] : []); } - 不要在模型里用
isset($this->appends)手动增删数组——$appends是只读声明，运行时修改无效
API 返回中 hidden 字段意外暴露，可能是 Eloquent 关系加载惹的祸
你以为 $hidden = ['password'] 很安全？但如果模型关联了 posts()，而 Post 模型没设 $hidden，且你用了 with('posts')，那 posts.*.user.password 可能出现在嵌套结构里。
这是因为 $hidden 只作用于当前模型实例，不自动透传到关联模型。JSON 序列化时，Eloquent 会递归调用每个关联模型的 toArray()，而那个模型若没隐藏敏感字段，就会原样输出。
- 每个关联模型都得单独配
$hidden，不能依赖父模型 - 用 API 资源类统一收口最稳妥，
PostResource里明确只返回需要的字段 - 调试时用
dd($model->load('posts')->toArray())看原始结构，比直接测接口更快定位泄露点
真正麻烦的不是规则本身，而是隐藏字段和动态 append 在嵌套关系、资源类、序列化上下文之间来回跳转——稍不注意，一个没配的关联模型就能让整个隐藏策略失效。
