hyperf model 通过 get{field}attribute/set{field}attribute mutator 拦截字段读写，实现敏感字段自动加解密；需封装加密逻辑至可注入的 cryptservice，避免递归、null 处理及硬编码密钥，并注意 where/update/select 等绕过场景。
Hyperf Model 中如何用 getMutator 和 setMutator 拦截字段读写
Hyperf 的 Model 支持通过命名约定的 mutator 方法拦截字段访问，这是实现自动加解密最轻量、侵入性最小的方式。它不依赖中间件或全局事件，只在模型层面生效，适合敏感字段（如 id_card、phone、email）的按需加密。
关键点在于：Hyperf 会自动识别形如 get{Field}Attribute 和 set{Field}Attribute 的方法，并在 $model->field 读取或赋值时触发。
- 字段名需为小写下划线风格（如
user_phone），对应 mutator 方法名为getUserPhoneAttribute/setUserPhoneAttribute - 加密逻辑应放在
setXxxAttribute中，解密放在getXxxAttribute中；数据库存的是密文，应用层看到的是明文 - 务必避免在 mutator 中调用
$this->attributes['xxx']直接读写，否则会触发无限递归 - 如果字段允许为
null，mutator 内需显式判断，否则null会被当成空字符串加密
加解密逻辑该放哪？推荐封装成独立 Service
把 AES 加解密逻辑硬写在 mutator 里会导致模型臃肿、难以测试，也违反单一职责。更合理的方式是抽离为一个可注入的 CryptService，通过构造函数或属性注入到 Model 中。
注意 Hyperf 的 Model 默认不是容器管理对象，不能直接 @Inject，需手动在构造函数中获取：
public function __construct(array $attributes = [])
{
parent::__construct($attributes);
$this->cryptService = ApplicationContext::getContainer()->get(CryptService::class);
}
-
CryptService应支持指定密钥、IV、算法（如AES-128-CBC），并统一处理 padding 和 base64 编码 - 避免使用静态方法调用加密工具类，否则无法 mock 单元测试
- 生产环境密钥严禁写死，建议从
config/autoload/crypt.php或 Vault 加载
为什么不能用 casts 实现自动加解密？
Hyperf（及 Laravel）的 $casts 属性仅支持基础类型转换（如 'created_at' => 'datetime'），底层调用的是 PHP 类型强制转换或 Carbon 构造，**不支持任意逻辑**。试图写 'phone' => PhoneCryptCast::class 会失败，因为框架不会实例化或调用自定义 cast 类的任何方法。
-
$casts是只读映射，仅影响toArray()、jsonSerialize()和属性赋值时的类型推导 - 即使继承
Castable接口，Hyperf 当前版本（v3.0+）仍未实现对自定义 cast 的完整支持 - 强行绕过用
setAttribute+getAttribute重写，会丢失批量赋值（fill()）、Eloquent 关系、JSON 序列化等行为的一致性
容易被忽略的边界问题：批量操作与原始查询
mutator 只在模型属性访问时生效，以下场景完全绕过加密逻辑，必须额外处理：
-
User::where('user_phone', $plain)->first()—— 这里查的是明文，但数据库存的是密文，必然查不到；应改用whereEncrypted('user_phone', $plain)扩展查询方法 -
User::query()->update(['user_phone' => $plain])—— 直接执行 SQL，mutator 不触发；需配合updating事件或重写update方法 -
User::select('user_phone')->get()—— 返回的是密文字符串，不会自动解密；需在 collection 上 map 或改用selectRaw("AES_DECRYPT(user_phone, ?) as user_phone", [$key]) - 软删除字段（
deleted_at）若参与加密，会导致withTrashed()查询异常，建议排除敏感字段的软删逻辑
真正落地时，加密字段往往需要配套的查询构建器扩展、迁移字段注释说明、以及 DB 备份前的解密脚本——这些都不是加两行 mutator 就能闭环的。
