Eloquent Attribute Pseudonymization 是开发者在 get/set 访问器中手动实现的可逆加解密，非框架原生功能；它可逆但不等于安全加密，需用对称加密或确定性令牌化，且必须保持原始数据格式与语义。
什么是Eloquent Attribute Pseudonymization，它真能“可逆”吗？
Eloquent 本身不提供原生的 pseudonymization（假名化）能力，所谓“可逆隐私保护”，实际是开发者在 get<em></em> / set 访问器中手动实现的加解密或哈希映射逻辑。关键点在于：可逆 ≠ 安全加密，而是指业务上能还原原始值——比如用对称加密（openssl_encrypt）或确定性令牌化（如 hash_hmac + salt + lookup table）。若用不可逆哈希（password_hash），就不是 pseudonymization，而是 anonymization。
- 假名化必须保留数据格式和语义（如手机号仍为11位字符串），否则下游校验、索引、搜索会出问题
- Laravel 的
casts不适用，因为它只做类型转换，不支持带密钥的加解密流程 - 直接在模型里写加解密逻辑时，务必避免把密钥硬编码进
git；推荐从config('app.pseudo_key')或env('PSEUDO_KEY')读取
怎么在 Laravel 模型中安全实现可逆的 get/set 属性访问器？
核心是利用 Eloquent 的 mutator/accessor 机制，在存取时自动套一层加解密。以手机号字段 phone 为例：
- 使用 AES-128-CBC 等对称加密，确保可逆且抗重放
- 加密前补零或标准化格式（如统一去空格、+86 前缀），避免相同号码因格式差异生成不同密文
- 解密失败时（如密文损坏、密钥变更），应抛出
DecryptException而非静默返回空，方便定位问题
class User extends Model
{
protected $fillable = ['phone'];
<pre class="brush:php;toolbar:false;">public function setPhoneAttribute($value)
{
if (! $value) {
$this->attributes['phone'] = null;
return;
}
$key = config('app.pseudo_key');
$ivlen = openssl_cipher_iv_length($cipher = 'AES-128-CBC');
$iv = openssl_random_pseudo_bytes($ivlen);
$encrypted = openssl_encrypt($value, $cipher, $key, 0, $iv);
$this->attributes['phone'] = base64_encode($iv . $encrypted);
}
public function getPhoneAttribute($value)
{
if (! $value) {
return null;
}
$key = config('app.pseudo_key');
$data = base64_decode($value);
$ivlen = openssl_cipher_iv_length($cipher = 'AES-128-CBC');
$iv = substr($data, 0, $ivlen);
$ciphertext = substr($data, $ivlen);
$decrypted = openssl_decrypt($ciphertext, $cipher, $key, 0, $iv);
return $decrypted === false ? null : $decrypted;
}}
注意：IV 必须随密文一起存储，且每次加密用新 IV；不能复用 IV，否则丧失安全性。
立即学习“PHP免费学习笔记（深入）”；
为什么不能直接用 Laravel 的 encrypted cast？
Laravel 9+ 引入了 encrypted cast，但它默认使用 encrypt_string，底层调用的是 Illuminate\Encryption\Encrypter，其密钥由 APP_KEY 衍生，且加密结果包含序列化头（base64 + serialize 结构）。问题在于：
- 加密后数据长度不稳定（可能超数据库字段限制，如
VARCHAR(255)存不下） - 无法跨 Laravel 版本或外部系统（如 Python 微服务）解密，因为
Encrypter实现细节不公开、不兼容标准 OpenSSL - 若 APP_KEY 轮换，历史数据无法解密（无密钥版本管理机制）
所以生产环境需自定义加解密逻辑，而非依赖框架内置加密 cast。
假名化字段还能走数据库查询和索引吗？
不能直接 where('phone', $raw)，因为数据库存的是密文。可行方案有：
- 查询时手动加密输入值再比对：
User::where('phone', encrypt_phone($input))->first() - 在数据库建虚拟列（MySQL 5.7+）或生成列，存哈希摘要（如
SHA2(phone, 256)）用于快速过滤，但注意哈希不可逆，仅作索引辅助 - 对高查询频次字段，额外维护一张
pseudo_mappings表，用随机 token 映射原始值，查 token 再 join 还原（更可控，但增加 JOIN 开销）
最常被忽略的是：假名化后，Eloquent 的 whereRaw、orderBy、groupBy 全部失效——你不能对密文做排序或分组，除非业务接受按密文字典序排（毫无业务意义）。需要排序/统计的字段，得另存明文摘要或设计降级方案。
