toarray() 默认不保留关联模型键名，会将关系扁平为数值索引数组；未预加载的关系不会出现；空关联输出[]而非null；推荐用$apends+accessor或jsonresource统一控制结构与语义。
toArray() 默认不保留关联模型的键名，会把关系字段扁平成数组索引
直接调用 Model::all()->toArray() 或 $model->toArray() 时，Laravel 会把关联模型（比如 belongsTo、hasMany）转成数值索引数组，而不是你定义的关系名作为键。例如 user->posts 变成 [{...}, {...}]，而不是 ['posts' => [{...}, {...}]] —— 这不是 bug，是默认行为。
根本原因是 Laravel 的 toArray() 底层依赖 array_merge_recursive 和递归遍历逻辑，对关系属性不做显式键名映射。
- 如果你用了
with('posts')预加载，但没在模型里声明$appends或重写toArray()，那posts字段压根不会出现在结果里 -
toArray()不会自动包含未加载的关系（哪怕有 accessor），必须显式load()或with() - 如果关联是空集合（比如用户没发过帖），默认输出
[]而不是null或['posts' => []]，容易让前端误判结构
用 $casts + 访问器（accessor）手动控制关联字段的键名和格式
最可控的方式不是改 toArray() 行为，而是把关联数据“变成”一个可序列化的属性。这样既能保键名，又能统一空值处理逻辑。
比如想让 User 模型输出带 'posts' 键的数组：
class User extends Model
{
protected $casts = [
'posts' => 'array',
];
protected $appends = ['posts'];
public function getPostsAttribute()
{
return $this->relationLoaded('posts')
? $this->posts->map->toArray()->all()
: [];
}
}
-
$appends是关键：它告诉toArray()把这个访问器当普通属性序列化 - 必须用
relationLoaded()判断是否已加载，否则每次访问都会触发 N+1 查询 -
map->toArray()是安全的，比直接$this->posts->toArray()更稳（后者可能抛错） - 别在
$casts里写'posts' => 'collection'—— Laravel 不认这个 cast 类型，会静默失败
toBase()->getAttributes() 不能替代 toArray()，它根本不处理关联
有人试过 $model->toBase()->getAttributes() 想绕过 Eloquent 层，结果发现：关联字段完全不出现，连空数组都没有。这是因为 toBase() 返回的是底层 Builder 实例，只管原始数据库字段。
-
getAttributes()返回的是$attributes数组，仅含 fillable + casts + mutators 处理过的字段 - 所有
with()加载的关联、append()添加的访问器，全被忽略 - 如果你真需要纯 DB 字段 + 手动拼关联，不如用
DB::table()做 join 查询，别硬套模型方法
复杂嵌套结构建议用 Fractal 或自定义 Resource，别死磕 toArray()
当关联层级超过两层（比如 user → posts → comments → author），靠访问器 + $appends 会迅速变得难维护：重复判断加载状态、嵌套 map、空值补全逻辑散落各处。
- Laravel 自带的
JsonResource是更合适的选择，它天然支持嵌套、条件包含、字段过滤 - 例如
UserResource::collection($users)可以统一控制posts是否展开、comments是否只取 id 和 content - 不要为了“省一次 new Resource()” 在控制器里堆
map()->toArray()，后期加个权限字段或时间格式化就会崩溃 - 如果项目已用 API 资源类，就别再碰
toArray()—— 它的设计目标只是调试和简单导出，不是 API 响应规范
真正难的不是怎么让键名留下，是怎么让“留下的键名”在不同场景下保持语义一致、空值可预测、扩展不爆炸。这点光靠方法名改来改去解决不了。
