Eloquent模型序列化需理清$hidden/$visible、toArray()触发时机及API资源冲突；toJson()返回{}多因模型为null；withoutRelations()可剥离已加载关联；加密字段推荐用Cast类脱敏。
直接返回 Eloquent 模型或集合，Laravel 会自动调用 toJson()；但若字段没按预期出现、JSON 为空、或敏感字段泄露，问题几乎都出在序列化控制逻辑没理清，而不是方法本身不会用。
toArray() 和 toJson() 什么时候真正生效
toArray() 不是“随时触发”的魔术方法，它只在明确进入序列化流程时才被调用：比如调用 toJson()、response()->json($model)、Blade 中直接 {{ $user }}（Laravel 9+ 默认启用），或者 API 资源的 toArray() 方法里显式调用它。它**不会**在 dd()、var_dump()、日志里执行——这时候你看到的是原始对象，含所有属性和关系，容易误判 $hidden 是否起作用。
常见错误现象：dd($user->toArray()) 显示了 password，但 response()->json($user) 却没返回 → 很可能漏写了模型的 $hidden 属性，仅靠手动调用 toArray() 覆盖不生效。
-
$hidden和$visible是底层控制开关，必须写在模型类里才对自动序列化生效 - 重写
toArray()会绕过 Laravel 的缓存优化（如结果复用），高频接口慎用复杂逻辑 - 若同时实现了
jsonSerialize()，会完全跳过toArray()，两者不要混用
toJson() 返回 {} 空对象的真正原因
toJson() 返回 {} 几乎从不是 JSON 编码失败，而是源头模型为 null 或空实例。例如 User::find(999)->toJson()，因查不到记录返回 null，而 null 经 json_encode() 就是 {}。
- 务必先判断存在性：
if ($user) { return $user->toJson(); }或用optional($user)->toJson() -
JSON_UNESCAPED_UNICODE可避免中文被转义，但别加JSON_PRETTY_PRINT上生产环境，体积膨胀且无缓存优势 - 模型未加载成功时，
toArray()也会返回空数组，本质同源
关联数据该不该序列化？用 withoutRelations() 控制输出范围
预加载了 with('posts')，但 API 只需用户基本信息？默认序列化会把整个 posts 数组嵌进去，增大响应体积、暴露无关数据。这时 withoutRelations() 是轻量级解法。
它不改查询、不删关系、不触发新查询，只是在序列化前“剥离”已加载的关联副本：
-
$user->withoutRelations()->toJson()→ 只含User自身字段 - 可链式调用：
$user->withoutRelations()->makeHidden(['password', 'remember_token'])->toJson() - 适用于“已加载用于业务判断，但不对外输出”的场景，不能替代合理查询设计（比如不该查的就别
with()）
敏感字段隐藏失败？检查 $hidden 和 API 资源是否冲突
$hidden = ['password'] 在模型里写了，但 API 响应里还是出现了？大概率是用了 API Resource，而 Resource 的 toArray() 没继承模型的隐藏规则——Resource 完全接管了序列化逻辑。
API Resource 更推荐用于精细化控制，但它和模型层的 $hidden 是两套机制：
- Resource 中要隐藏字段，得手动不返回：
'email' => $this->email不写，就不出现在 JSON 里 - 想复用模型的
$hidden，可用$this->resource->toArray()获取基础数组再过滤，但失去 Resource 的条件字段（when()）、嵌套资源等优势 - 加密字段等特殊处理，建议用自定义
Cast类，在toArray()前就完成脱敏，比藏在$hidden更可靠
最易被忽略的一点：模型序列化时，$appends 添加的字段（如 is_admin）会参与 $hidden 判断，但访问器方法名必须严格是 getIsAdminAttribute() 形式，少下划线或多参数都会失效。
