模型层 $hidden 是硬开关，仅在自动序列化（如 response()->json()）生效；dd($user->toArray()) 绕过该逻辑，显示裸数组；关联模型需单独设 $hidden；$visible 优先级高于 $hidden；动态字段推荐 $appends + 访问器；toJson() 返回 {} 多因模型为 null；withoutRelations() 可剔除已加载的关联数据。
直接在模型类里配 $hidden 或 $visible，是最稳、最省事的起点；别指望靠控制器里临时 toArray() 覆盖能生效，那只是骗自己。
为什么 response()->json($user) 不显示 password，但 dd($user->toArray()) 却有？
因为 $hidden 是模型层的硬开关，只在自动序列化流程（如 response()->json()、toJson()、Blade 中直接输出）里起作用；而 dd($user->toArray()) 是你手动调用，它绕过了模型的隐藏逻辑——这时候看到的是“裸数组”，不是最终 API 输出。
- 真正生效的前提：模型类里必须声明
protected $hidden = ['password'] -
$hidden对关联模型（比如$user->posts）无效，得去Post模型里单独设 - 若同时定义了
$visible，$hidden会被无视——白名单优先级更高
想加一个动态字段，比如 is_admin，该用 $appends 还是重写 toArray()？
$appends 更安全、更可复用；重写 toArray() 是“全盘接管”，容易踩坑且禁用 Laravel 的缓存优化。
- 用
$appends：在模型里写protected $appends = ['is_admin']，再配getIsAdminAttribute()访问器，返回布尔值即可 - 访问器名必须是
getXXXAttribute格式，XXX 首字母大写，对应属性名小写（is_admin→getIsAdminAttribute） - 重写
toArray()适合极少数场景：比如要根据请求头语言动态拼接字段，或条件性排除整个子数组——但要注意 N+1 风险，别在里面查数据库
toJson() 返回 {} 空对象，是不是 JSON 编码失败？
几乎从来不是。99% 是模型实例为 null，比如 User::find(999) 没查到数据，null->toJson() 就是 {}。
- 务必先判断存在性：
if ($user) { return $user->toJson(); }或用optional($user)->toJson() -
toJson(JSON_UNESCAPED_UNICODE)可避免中文被转义成 \uXXXX，但别加JSON_PRETTY_PRINT上生产——体积大、无缓存优势 - 如果用了自定义
jsonSerialize()方法，会完全跳过toArray()，两者不能共存
关联数据太多，怎么只序列化主模型，不带 with() 加载的 posts？
用 withoutRelations()，轻量、不改查询、不触发新请求，专治“已加载但不该发出去”的场景。
-
$user->withoutRelations()->toJson()→ 只含User自身字段，posts键彻底消失 - 可链式组合：
$user->withoutRelations()->makeHidden(['password'])->toJson() - 它不解决“不该查却查了”的问题——预加载本身是否必要，得回业务逻辑里审视；
withoutRelations()只是最后一道输出闸门
最常被忽略的其实是“关联是否真正加载”：没用 with() 或 load()，toArray() 就当它不存在，连键都不留；调试时看到 $user->posts 有值，不代表 toArray() 一定会包含它。
