Eloquent 没有内置 Attribute Anonymization 机制，它只是社区对访问器脱敏的俗称；原始数据仍明文存库，真正隐私保护需加密存储（如 encrypted cast）+ 按需脱敏展示。
什么是 Eloquent Attribute Anonymization，它真能保护隐私？
不能。Eloquent 本身没有 Attribute Anonymization 这个内置机制——这是社区对“在模型中自动脱敏敏感字段”的一种通俗叫法，并非 Laravel 官方术语。它本质是利用访问器（get{Attribute}Attribute）或 casts + 自定义 Cast 类，在读取时动态替换值（如手机号变 138****1234），但原始数据仍明文存于数据库。真正保护隐私靠的是：字段加密存储（用 encrypted cast 或手动加解密）+ 读取时按需脱敏（非强制）。混淆这两者，容易误以为“用了访问器就安全了”，结果审计时发现数据库里全是明文身份证号。
用 Accessor 实现读取时脱敏：简单但有陷阱
最常见做法是在模型里写访问器，比如隐藏手机号：
public function getPhoneAttribute($value)
{
if (empty($value)) return $value;
return substr($value, 0, 3) . '****' . substr($value, -4);
}
这看似有效，但要注意几个实际问题：
- 该访问器对所有调用
$user->phone的地方生效，包括 API 输出、日志、队列任务里的调试 dump —— 你可能在后台导出 Excel 时也意外脱敏了 - 如果后续需要真实手机号发短信，就得绕过访问器用
$user->getRawOriginal('phone')，代码分散且易遗漏 - JSON 序列化（
toArray()/toJson()）默认走访问器，无法单独控制“API 返回脱敏，管理后台不脱敏” - 搜索、排序、where 条件仍基于原始值，不会因访问器改变行为
更可控的方式：用自定义 Cast 做存储加密 + 可选脱敏
真正兼顾安全与灵活性的做法，是把“加密存储”和“读取展示”拆开。推荐用 Laravel 9+ 的 AsEncryptedString 配合一个轻量级脱敏访问器：
立即学习“PHP免费学习笔记（深入）”；
protected $casts = [
'id_number' => 'encrypted',
'phone' => 'encrypted',
];
再加一个可选的脱敏访问器（仅用于展示场景）：
public function getPhoneMaskedAttribute()
{
$raw = $this->getDecryptedValue('phone');
return $raw ? substr($raw, 0, 3) . '****' . substr($raw, -4) : null;
}
这样你能明确区分：
-
$user->phone→ 返回解密后的原始值（可用于业务逻辑） -
$user->phone_masked→ 明确只用于前端展示，语义清晰 - 数据库里永远是加密 blob，即使被拖库也无法直接还原
注意：Laravel 的 encrypted cast 依赖 APP_KEY，换密钥后旧数据无法解密；生产环境切密钥前必须做数据迁移。
API 层统一脱敏：避免在每个模型里重复写逻辑
当脱敏规则复杂（如不同角色看到不同精度）、或涉及多个模型时，在模型层硬编码访问器会失控。更可持续的做法是抽到响应层：
- 用 API Resource（如
UserResource）统一处理字段映射：'phone' => $this->whenAuthCan('view-full-phone', $resource->phone, $resource->phone_masked) - 结合策略（Policy）控制权限，而不是靠字段名判断是否脱敏
- 避免在控制器里写
unset($data['id_number'])这类临时补丁，它绕过模型生命周期，下次加新字段就漏掉
真正的难点不在怎么写脱敏逻辑，而在于厘清“谁有权看什么”——这得靠 Policy + Gate + Resource 组合，不是单靠一个访问器能解决的。
