toArray仅在显式序列化时调用（如toJson、response()->json、Blade输出），dd/var_dump/日志中不触发；漏写$hidden会导致dd显示password但API不返回；重写toArray会禁用Laravel缓存优化。
toArray 什么时候被自动调用
toArray 不是魔法函数，它只在明确触发序列化逻辑时才执行，比如调用 toJson()、response()->json()、或 Blade 中直接输出模型对象（Laravel 9+ 默认启用自动转换）。但注意：它**不会**在 dd()、var_dump() 或日志里被调用——这时候你看到的是原始对象结构，容易误判字段是否生效。
- 常见错误现象：
dd($user->toArray())显示了password字段，但response()->json($user)却没出现 → 很可能漏写了hidden属性，仅靠toArray()覆盖不生效 - 使用场景：需要统一过滤敏感字段时，优先靠模型的
$hidden或$casts控制，toArray()适合做「额外动态处理」，比如拼接头像完整 URL - 性能影响：重写
toArray()会阻止 Laravel 的默认缓存优化（如toArray()结果不复用），高频接口慎用复杂逻辑
toJson 输出为空对象 {} 的原因
toJson() 返回空对象，几乎一定是模型实例未加载成功，或者被强制转成了空数组。不是 JSON 编码失败，而是源头数据丢了。
- 常见错误现象：
User::find(999)->toJson()返回{}→ 实际是null被转成空对象，应先判断是否存在：optional($user)->toJson()或if ($user) { ... } - 参数差异：
toJson(JSON_UNESCAPED_UNICODE)可避免中文被转义，但别加JSON_PRETTY_PRINT上生产，体积大且无缓存优势 - 兼容性影响：Laravel 10 默认用
JsonSerializable接口，若手动实现jsonSerialize()方法，会完全绕过toArray()，两者不要混用
定制字段时 $appends 和 toArray 哪个优先
$appends 是声明式扩展，toArray() 是命令式覆盖——后者能删、改、加任意字段，但代价是失去框架对附加属性的类型转换和缓存支持。
- 使用场景：加一个计算字段（如
full_name）用$appends更安全；要根据请求参数动态决定是否包含某个字段（如管理员才显示last_login_ip），就得重写toArray() - 容易踩的坑：
$appends里的访问器方法名必须是getXXXAttribute()形式，且不能带参数；而toArray()里可以自由调用带参方法，但要注意 N+1 查询风险 - 示例：
protected $appends = ['is_admin']; public function getIsAdminAttribute() { return $this->role === 'admin'; }—— 这比在toArray()里硬写'is_admin' => $this->role === 'admin'更利于复用和测试
序列化关联模型时循环引用怎么破
Laravel 默认递归序列化关联关系，一旦出现双向关联（比如 User → Post → User），toJson() 会抛出 Exception: Maximum function nesting level of '256' reached 错误。
- 根本解法：用
withoutRelations()或显式指定加载的关联，例如$user->load('posts.author')改成$user->load('posts')，切断深层链路 - 临时规避：在模型中设置
protected $relations = [];可清空所有已加载关联，但会丢数据，慎用 - 更稳妥的做法：用 API Resource 类替代裸模型序列化，它天然隔离循环，且支持条件加载：
new UserResource($user)内部可控制是否包含posts，以及posts是否再包含author
toArray，而是想清楚哪些字段该由模型管、哪些该交给 Resource 或 DTO —— 混在一起改，早晚掉坑里。 
