ThinkPHP如何实现数据脱敏_手机号邮箱中间星号掩码处理【指南】

处理用户数据脱敏，尤其是手机号和邮箱这类高频字段，很多团队一开始想的是“加个配置开关”，或者在控制器里统一处理一下。但实际落地就会发现问题：用 toArray() 返回 API、做 Excel 导出、写日志……但凡漏掉一个环节，明文数据就暴露了。

所以，关键不在于用什么函数，而在于把脱敏逻辑写死在模型层——用访问器（Accessor）让它成为数据输出的默认行为。下面直接聊实现和几个容易踩的坑。

手机号脱敏必须用 getMobileAttr + substr_replace

一眼看上去，substr($mobile, 0, 3) . '****' . substr($mobile, -4) 就能解决问题，对吧？实际一跑，空值、非字符串、国际号（+86138…）全给你崩出花来。

正确的姿势首先是一个严格命名的访问器：getMobileAttr（字段名首字母大写 + Attr，少一个字母都不触发）。里面必须判空：if (empty($value) || !is_string($value)) { return $value; }。然后用 substr_replace($value, '****', 3, 4) 替换第4到第7位字符，这个方法比正则快，而且没有 PCRE 依赖问题。

如果系统存了国际号码格式，比如 +86 138 1234 5678，上面这套直接崩。一个稳妥的兼容方案是先清洗数字：$clean = preg_replace('/[^0-9]/', '', $value);，然后对清理后的纯数字串做掩码替换，保证最后输出是 138****5678 这种干净格式。

邮箱脱敏不能只截用户名，得保留域名结构

邮箱的掩码逻辑比手机号更容易出问题。常见的两种错误写法：zhang***@example.com 和 z***@e***.com——前者容易让攻击者根据首尾字符猜出完整用户名，后者直接破坏了域名可读性，调试的时候非常痛苦。

正确做法：通过 explode('@', $value, 2) 拆出本地部分和域名部分。只对本地部分的中间字符做掩码：如果本地部分长度大于2，就保留首尾字符，中间全部替换为星号；如果长度小于等于2（比如 ab@xx.com），就整个掩掉。域名保持原样，example.com 怎么进来的就怎么出去，不影响识别。

同样别忘了空值判断——!isset($local) || !$domain 时直接返回原始值，避免 null 或格式异常导致整个请求挂掉。

关联模型脱敏不会自动继承，每个子模型都要单独定义

这个坑很多人遇到了才意识到：User 模型里明明写了 getMobileAttr，但用 with('profile') 查出来的 Profile 模型里的 phone 字段，照样明文输出。ThinkPHP 不会递归地去子模型里应用父模型定义的访问器。

解决办法是在 Profile 模型里也写一遍 getPhoneAttr。如果多个模型共用同一套规则（比如手机号、邮箱、身份证），抽成一个 Trait 是最干净的方案：一行 use AnonymizeFields; 解决问题，不用到处复制粘贴。

需要特别提醒的是：withAttr 只适用于单次查询的临时覆盖，绝对不能用来替代模型层的访问器。原生查询 Db::table('user')->select() 更是完全绕过所有访问器，脱敏彻底失效，这一点在代码审查时要高度警惕。

导出 Excel 或日志记录时，脱敏逻辑最容易被绕过

导出通常走 $list->each() 回调或者直接用 getData() 取原始值——这两个操作默认跳过访问器。getData('mobile') 拿到的就是明文，toArray(true) 同样不会触发 getMobileAttr。换句话说，开发环境跑着一切正常，一导出就出事。

导出前统一走 collection 处理是最保险的：$list->each(fn($u) => $u->mobile = hide_mobile($u->mobile));。日志记录更是不能图省事直接丢 $order->toArray()，必须先用白名单过滤出需要脱敏的字段：['mobile', 'email', 'id_card']，再逐字段处理。

TP6.1 及以上版本可以用 $user->getAttr('mobile', null, false) 显式禁用访问器，但这个语法糖只适合需要明文的极少数场景，比如后台管理员查看原始号码。测试阶段务必用真实数据跑一遍导出文件，打开 Excel 确认单元格里显示的是 138****5678 而不是原始号码——亲眼确认是最低成本的防漏手段。

回过头来看，真正难的不是写几个星号替换，而是厘清这些字段在哪些路径下必须脱敏、哪些接口允许明文、规则是否随用户角色动态变化。这些逻辑一旦散落在控制器、导出方法、日志封装里各自处理，下一次改掩码长度就等于全线重测。所以，核心思路很简单：把脱敏逻辑收拢到模型层，用访问器兜底，然后针对导出和日志这两个最容易绕过的节点，单独做一层强制校验。