toArray() 字段不一致是因hidden/visible不透传关联模型、append需显式声明、日期格式受全局控制；应优先用visible()/hidden()动态限定，复杂场景改用自定义数组或资源类。
为什么 toArray() 返回的字段和预期不一致
ThinkPHP 的 toArray() 默认会把模型所有属性（包括隐藏字段、关联数据、计算字段）一股脑塞进去，尤其当你设置了 hidden 或 visible 属性，但又在关联模型里没同步配置时，结果就容易漏掉或混入不该有的字段。这不是 bug，是它按“当前模型定义”逐层展开的逻辑导致的。
-
hidden和visible只作用于本模型，不会自动透传给with()加载的关联模型 - 如果用了
append添加了获取器（如getFullnameAttr），默认也不会出现在toArray()结果里，除非显式调用withAttr()或设置append到模型属性中 - 日期字段默认转成字符串，但格式由全局
datetime_format控制，不是每个接口都需要统一格式
如何精准控制 toArray() 的输出字段
最直接的办法是在调用前用 visible() 或 hidden() 动态限定字段，比改模型类更灵活，也避免污染复用逻辑。
- 只保留指定字段：
$user->visible(['id', 'name', 'email'])->toArray() - 排除敏感字段：
$user->hidden(['password', 'salt'])->toArray() - 对关联模型单独处理：
$user->with(['profile' => function($q) { $q->hidden(['id', 'user_id']); }])->toArray() - 想让获取器生效？得提前声明：
$user->append(['fullname'])->toArray()，否则getFullnameAttr不触发
toArray() 与 toJson() 在过滤逻辑上的关键差异
toJson() 内部其实调用了 toArray()，但多了一步 JSON 编码前的类型归一化——比如把 DateTime 实例转成字符串、Collection 转成数组。所以如果你发现 toJson() 有字段而 toArray() 没有，大概率是字段被 hidden 拦截了；反之，如果 toArray() 有而 toJson() 没有，检查是否字段值为 null 或不可 JSON 序列化的对象（如 PDOStatement）。
-
toJson()会跳过值为null的字段（除非显式设置JSON_UNESCAPED_UNICODE | JSON_FORCE_OBJECT） -
toArray()不做空值过滤，null字段照常出现 - 两者都受模型的
$json` 属性影响（如 <code>$json = ['status'];表示该字段仅在 JSON 场景下输出）
自定义序列化逻辑：绕过 toArray() 的几种务实做法
当过滤规则变得复杂（比如不同 API 接口要不同字段集、需运行时计算、要合并多个模型字段），硬塞进 toArray() 链式调用反而难维护。这时候更适合主动构造数组。
立即学习“PHP免费学习笔记（深入）”；
- 用原生数组组装：
['id' => $user->id, 'name' => $user->name, 'avatar' => $user->avatarUrl]，简单清晰，无隐式行为 - 封装一个
toApiArray()方法到模型里，内部按业务场景判断：if ($this->is_admin) { ... } - 配合资源类（Resource）思路：新建
UserSimpleResource类，只暴露基础字段；UserDetailResource加入关联和计算字段——虽然 TP 官方没 Resource 概念，但自己写个轻量类完全可行
真正麻烦的从来不是怎么过滤，而是「哪些字段该在哪个接口出现」这件事本身没沉淀成规则。一旦开始靠 if-else 拼数组，就该回头看看字段权限是不是该抽成配置或注解了。
