ThinkPHP需用模型访问器（如getMobileAttr）或withAttr实现手机号、身份证号脱敏，不可依赖控制器遍历；脱敏函数应抽离为独立工具方法，关联查询需显式声明子模型脱敏，原生查询会绕过脱敏逻辑。
查询结果中自动对手机号、身份证号脱敏
ThinkPHP 本身不内置字段脱敏逻辑，得靠 withAttr 或模型的 get*Attr 访问器手动处理。这不是“配置一下就生效”的功能，而是要你明确告诉框架：“这个字段查出来时，别直接返回原始值”。
常见错误是把脱敏写在控制器里逐条遍历，既重复又漏判（比如关联查询、toArray()、JSON 输出都可能绕过）。
- 优先用模型访问器：
getMobileAttr处理mobile字段，只要字段名匹配，所有查询、序列化、API 返回都会自动走它 - 如果字段名不固定或需动态控制，用
withAttr：比如User::withAttr('id_card', fn($v) => hideIdCard($v)) - 注意访问器只对读取生效，
save()或写入时不会触发，原始值照存
脱敏函数别硬编码在模型里
把 substr_replace 或正则写死在 getMobileAttr 里，后续想统一改规则（比如从「138****1234」变成「138****234」）就得挨个改模型，维护成本高。
推荐抽成独立函数，放在 app/common/Helper.php 或 app/utils/Desensitize.php，然后在访问器里调用：
立即学习“PHP免费学习笔记（深入）”；
public function getMobileAttr($value)
{
return desensitize_mobile($value);
}
这样既能复用，也方便单元测试——比如传空值、null、11位以外字符串时是否仍安全。
- 手机号脱敏建议用
preg_replace('/^(\d{3})\d{4}(\d{4})$/', '$1****$2', $v)，比substr更防异常长度 - 身份证号慎用
substr($v, 0, 6) . '******' . substr($v, -4)，得先判断长度和校验码是否合法，否则可能脱敏出错还报错 - 数据库里存的是明文，脱敏纯属展示层行为，别误以为加了访问器就等于数据加密
关联查询时脱敏失效怎么办
用 with('profile') 查用户+资料时，profile 模型里的敏感字段不会自动触发其自身的访问器——ThinkPHP 默认只对主模型生效。
必须显式声明子模型的脱敏字段：
User::with(['profile' => function ($query) {
$query->withAttr('id_card', fn($v) => desensitize_id_card($v));
}])->find();
或者更彻底：在 Profile 模型里也定义好 getIdCardAttr，再确保关联定义里启用了自动转换（默认开启，但若手动关了 autoWriteTimestamp 等，可能连带影响）。
- 关联预载入（
with）和关联属性访问（$user->profile->id_card）走的是不同路径，后者会触发子模型访问器，前者不一定 - 如果用
together合并查询或join，字段已变成数组键，访问器完全不生效，只能靠collection->each()后处理 - API 接口返回前用
hidden+append控制字段，比到处写withAttr更集中
JSON 输出时脱敏被跳过
json_encode($user) 或接口直接 return $user 时，ThinkPHP 会调用模型的 toArray()，此时访问器正常工作；但如果中间经过了 array_merge、collect() 转集合、或用了 Db::table()->select() 这类原生查询，就彻底脱离模型上下文。
最稳妥的方式是：所有对外输出的数据，统一走模型实例，避免混用 Query 和 Model。
- 别用
Db::name('user')->field('id,mobile')->select()，改用User::field('id,mobile')->select() - 如果必须用原生查询（比如复杂 UNION），脱敏逻辑得放到 Controller 层，且必须覆盖所有出口（JSON、Excel 导出、日志打印）
-
toJson()方法可接受参数JSON_UNESCAPED_UNICODE，但不影响脱敏逻辑，只是字符编码层面的事
脱敏不是加个钩子就一劳永逸的事，它依赖模型生命周期、查询方式、数据流转路径。哪个环节跳出模型控制，哪个环节就可能裸奔。
