直接在模型里设$hidden数组最简单可靠，它在toArray()、toJson()、API Resource自动调用等所有序列化场景中硬排除敏感字段，但仅作用于当前模型属性名，不继承至关联模型，也不与$visible混用。
直接在模型里设 $hidden 数组是最简单、最可靠的方式，它会在所有序列化场景（toArray()、toJson()、API Resource 自动调用）中生效，不需要额外判断或中间层。
用 $hidden 排除敏感字段最直接
它只作用于当前模型实例的属性名（即数据库字段名或访问器返回的键名），不是列名也不是别名。常见错误是把 password_hash 放进 $hidden，但实际字段叫 password——这会导致隐藏失效。
-
$hidden是硬排除：只要模型被转成数组或 JSON，就一定不出现，不管是不是 API 路由、有没有用 Resource - 关联模型不会继承这个设置，
User设了$hidden = ['password']，$user->profile里的Profile模型仍需单独定义$hidden - 别和
$casts混用：比如$casts = ['password' => 'encrypted']后再想靠$hidden隐藏，字段可能已解密并暴露
示例：
class User extends Model
{
protected $hidden = ['password', 'remember_token', 'email_verified_at'];
}
为什么 makeHidden() 对关联模型没用
因为 makeHidden() 只修改当前模型实例的原始属性列表，不递归处理关联集合。调用 $user->load('posts')->makeHidden(['email'])，$user 的 email 会消失，但每个 Post 实例仍完整输出，包括它的 user 关联里的 email。
- 想隐藏关联模型字段，得单独对集合操作：
$user->posts->makeHidden(['content']) - 更稳妥的是在关联模型里直接定义
$hidden，比如Post类里写protected $hidden = ['content'] - 如果嵌套深（如
posts.comments.user），makeHidden()完全不适用，必须用 Resource 或手动unset
API Resource 中别绕过 $hidden 规则
Resource 的 toArray() 方法里如果直接写 return $this->resource->toArray()，等于提前触发了一次序列化，$hidden 已生效，但你后续加的逻辑（比如条件字段）可能被覆盖；更糟的是，如果你返回的是未处理的模型对象（如 'user' => $this->user），makeHidden() 根本不会触发。
- 正确做法是显式调用：
'user' => $this->user->makeHidden(['api_token'])->toArray() - 或者在构造 Resource 时就处理：
new UserResource($user->makeHidden(['token'])) - 注意：如果模型用了
$visible白名单模式，makeHidden()会被忽略——Laravel 严格按白名单输出
$visible 和 $hidden 别混用
两者互斥：$visible 优先级高于 $hidden。一旦定义了 $visible，$hidden 就完全失效，哪怕只列了一个字段，其他所有字段（包括 id）都会被砍掉。
-
$visible适合极简响应场景（如只返回id和name），但维护成本高：新增字段必须同步加进$visible，否则消失 -
$hidden更符合最小权限原则，也更贴近真实开发节奏——你通常知道哪些要藏，而不是哪些要露 - 别在同一个模型里同时定义两者，Laravel 不报错，但行为不可预测
复杂点在于：字段可见性规则在多个层级叠加时（模型 $hidden + makeHidden() + Resource toArray()），最终结果取决于执行顺序和是否触发了序列化，而不是配置本身。最容易被忽略的是——调试时用 dd($user) 看到的结构，和 API 返回的结构，可能根本不一样。
