ThinkPHP模型字段动态隐藏必须在查询后、输出前通过visible()手动控制，因hidden属性为静态配置且不支持运行时逻辑；需按角色构造allowedFields数组传入visible()，并确保关联模型同步过滤。
ThinkPHP 模型字段不能靠模型本身动态隐藏，必须在查询后、输出前做字段过滤——这是最常被误解的点。
为什么 hidden 属性不适用于角色级动态隐藏
ThinkPHP 的模型 hidden 是静态配置，写死在类里，比如 ['password', 'salt']，它对所有请求一视同仁。一旦设了，不管当前用户是管理员还是访客，这些字段永远不出现在 toArray() 或 JSON 输出里。
真实业务中，你可能希望：管理员能看到 id_card，普通用户看不到；财务角色能看到 salary，其他角色看不到——这种“按角色开关字段”的逻辑，hidden 做不到。
常见错误现象：hidden 里硬塞变量或闭包（如 hidden => [$this->getRoleHiddenFields()]），结果毫无效果，因为框架初始化模型时就已解析并缓存该数组，不会运行任何逻辑。
用 visible + 角色判断控制字段可见性
比“隐藏”更可控的方式是反向思维：只声明当前角色允许看到的字段，其余一律不出现。这需要手动构造 visible 数组，并在序列化前传入。
- 在控制器或服务层，根据当前用户角色查出允许显示的字段列表，例如：
$allowedFields = ['name', 'email', 'phone'] - 调用
toArray()时传参：$user->visible($allowedFields)->toArray() - 若用
toJson()，需先转数组再编码：json_encode($user->visible($allowedFields)->toArray())，直接toJson()不会识别运行时visible() - 注意：该方式只影响当前实例，不影响后续查询或模型默认行为，安全边界清晰
避免在模型里写权限逻辑的三个理由
有人试图在模型的 toArray() 方法里加角色判断，甚至重写 __toString()，这会导致严重问题：
- 模型职责混乱：模型只管数据结构和关系，不该感知用户身份或权限系统
- 缓存污染：ThinkPHP 的模型属性缓存（如
data、origin）可能复用，导致上一个用户的字段规则影响下一个用户 - API 复用困难：同一个模型实例可能被多个接口消费，有的要全字段，有的要精简，混在模型里无法灵活切换
正确做法是把字段策略下沉到响应组装层（如 API 资源类、DTO 构造器），或者封装成独立的 filterFields(User $user, array $data) 工具函数。
withAttr 不适合敏感字段过滤
withAttr 是用来做字段读取时的值转换（比如把时间戳转日期字符串），不是字段存在性控制。哪怕你在 withAttr 里返回 null 或空字符串，字段依然会出现在输出里——只是值变了。
典型误用：protected $withAttr = ['id_card' => 'hideIdCard']，然后在 hideIdCard 方法里返回 ''。结果是 JSON 里仍有 "id_card": ""，前端仍能发现该字段存在，且可能被绕过校验。
真正要“消失”，就得让字段不出现在数组键里，只能靠 visible() 或手动 array_intersect_key() 过滤。
最易被忽略的一点：字段过滤必须发生在所有关联数据加载完成之后。如果用了 with('profile')，得确保 profile 模型也做了同样角色校验，否则主表字段藏好了，关联表把敏感字段全吐出来了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
