ThinkPHP如何实现敏感数据权限脱敏_字段级权限过滤技巧

在 ThinkPHP 6 里做敏感数据脱敏，很多开发者第一时间会想到 hidden 和 visible 这两个属性。但说实话，它们只能管序列化时字段的显示或隐藏，根本没法跟用户权限挂钩。真正要做到按角色、按权限动态过滤字段，得把逻辑下沉到查询阶段或者数据转换阶段去。

先说个重要判断：如果你指望在模型里写死 protected $hidden = ['id_card', 'phone'] 就能实现权限控制——那基本等于把门锁装在表面，有心人稍微绕一下就打开了。这不叫脱敏，这叫静态掩码，管理员和普通用户拿到的数据完全一样。

正确的思路是：把脱敏逻辑跟用户上下文绑在一起，在数据被真正使用之前，就按角色裁剪好。下面把几种常用的方案拆开来说。

append + 自定义访问器：轻量方案，但容易踩坑

用 append 动态追加一个脱敏字段，然后在访问器里写权限判断——这确实是最快捷的方式，但也是最容易失控的。

怎么个容易失控？最常见的情况是：你定义了 phone_masked 访问器，里面写了 $this->authUser->can('view_phone')，结果调用的时候 authUser 是 null，脱敏直接反水，原始手机号照常返回。问题出在你没在调用前把用户实例传进去。

正确做法是：在控制器里显式调用 $user->setAuthUser($request->user())，然后在访问器里判断：if ($this->authUser && $this->authUser->can('view_phone')) { return $this->phone; }。

不过要警惕另一个问题：如果你已经用 select * 查出了所有字段，再去调用 append(['phone_masked']) 做脱敏——那其实只是在已经暴露的数据上盖了层布。虽然对外输出控制了，但内存里数据早就全量存在，算不上真正的源头控制。

field 动态裁剪：从 SQL 层彻底隔离

这才是真正从喷泉口就开始限制的方案：根据用户角色，决定 SELECT 时取哪些字段。这不仅能减少网络传输，还能避免敏感数据在服务端内存里残留。

具体怎么干？先定义好不同角色的字段映射表：

'admin' => ['id', 'name', 'phone', 'id_card']
'user' => ['id', 'name']

然后在查询前拿到当前角色对应的字段数组：UserModel::field($allowedFields)->select()。至此，非管理员连 id_card 和 phone 的字节都看不到。

需要注意两个细节。一是 field 只影响主模型查询，关联模型不受影响。如果用 with 加载关联，得在关联定义里单独做字段限制，比如 User::has('profile')->field(['nickname'])。二是一个稳妥的思考顺序：字段裁剪越早做越好，别等到数据都查出来再去折腾访问器。

资源类（Resource）：最干净的落点

如果你在用 ThinkPHP 6.1+ 的资源类机制，那这里就是脱敏逻辑最理想的家。因为 toArray() 方法发生在数据查完之后、响应输出之前，这个时机既可控又与业务逻辑解耦，特别适合做字段级权限裁剪。

但实际操作中有一个容易踩的坑：Resource 实例默认没有用户上下文，你拿不到当前请求的认证信息。如果你直接在 toArray() 里写 $this->authUser，大概率是 null。

解决方案很简单：构造 Resource 时把用户传进去——new UserResource($user, $request->user())。在 Resource 类里保存 $this->authUser，然后在 toArray() 中按需返回字段。但有一点必须记住：不要在 Resource 里直接修改原始模型（比如调用 $this->resource->hidden = [...]），这会污染模型状态，副作用难以预期。

如果权限逻辑比较复杂——比如“普通用户只能看自己的手机号，管理员能看所有人的”——建议把这些判断抽成独立的服务类或者策略类，Resource 只负责调用，不写判断逻辑。这样既保证了 Resource 的纯粹性，也方便维护和测试。

说到底，字段级权限过滤不是加一行配置就能解决的问题。它得跟认证上下文、查询时机、数据流转阶段咬合在一起。任何一个环节断裂，脱敏就只是障眼法。从业务出发，选择适合自己项目阶段的方案，比盲目套用某个写法要重要得多。