laravel模型字段加密应优先使用mutator或casts，避免控制器手动加解密；存量数据迁移须用eloquent逐条处理；加密字段不可用于查询排序，需设计替代索引字段。
用 encrypt() 和 decrypt() 处理模型字段最直接
Laravel 自带的加密能力足够应对多数敏感字段（如手机号、身份证号），不需要额外装包。关键不是“能不能加解密”，而是“什么时候加、谁来加”。模型的 getMutator 和 setMutator 是最自然的落点——它把加解密逻辑锁死在属性访问层，业务代码完全无感。
常见错误是直接在控制器里手动调用 encrypt() 再存进数据库，结果后续查出来还是明文、或者重复加密导致解密失败。必须让框架接管整个生命周期。
- 在模型中定义
setPhoneAttribute($value)：内部调用encrypt($value)后存入$this->attributes['phone'] - 定义
getPhoneAttribute($value)：对decrypt($value)结果做空值判断，避免解密失败抛异常 - 确保数据库字段类型是
TEXT（AES 加密后是 base64 字符串，长度远超原始值） - 别给加密字段加
fillable或casts，mutator 会绕过它们
用 casts 配合自定义 Cast 类更可控
当多个字段要加密、或需要差异化处理（比如有的字段允许为空、有的必须非空、有的要兼容旧数据），硬写 mutator 会越来越难维护。casts + 自定义 Cast 是 Laravel 7+ 推荐路径，它把加解密封装成可复用、可测试的单元。
容易踩的坑是 Cast 类没实现 get() 和 set() 的异常兜底：比如数据库里存的是空字符串或 null，decrypt() 会直接报 DecryptException。必须在 Cast 里捕获并返回合理默认值。
- 创建类
EncryptedStringCast，实现Castable接口 -
set()中对$value做空值检查，避免加密 null 导致解密时崩溃 -
get()中用try/catch捕获Illuminate\Contracts\Encryption\DecryptException - 在模型里声明
protected $casts = ['id_card' => EncryptedStringCast::class];
数据库迁移时字段加密不能靠 DB::raw() 批量更新
上线前要把存量明文数据加密？别用 DB::raw("AES_ENCRYPT(...)")。Laravel 的加密密钥和 IV 机制与 MySQL 内置 AES 函数不兼容，硬套会导致全部数据变废。
真正可行的方式只有一种：用 Laravel 的 Eloquent 逐条读取 → 解密（如果是旧加密）→ 重新加密 → 保存。虽然慢，但唯一能保证密钥、填充方式、序列化格式一致。
- 写一个 Artisan 命令，用
chunkById(100)分批处理，避免内存溢出 - 对每条记录，先用
$model->setAttribute('phone', $model->phone)触发 mutator 或 cast - 显式调用
$model->saveQuietly()避免触发事件和验证干扰 - 加日志记录失败 ID，方便断点续跑
加密字段无法用于 where 查询或排序
这是加密的必然代价：密文不可预测、不可比较。你没法写 where('phone', 'like', '%138%')，也没法 orderBy('id_card')。任何想“查加密字段”的需求，本质都是设计缺陷。
真实场景里，搜索/筛选敏感信息几乎都靠关联脱敏标识（如用户 ID）、或引入单独的索引字段（如手机号前三位哈希）。试图绕过这个限制，最后都会变成性能黑洞或安全漏洞。
- 需要模糊搜索手机号？存一个
phone_prefix_hash字段，值为hash_hmac('sha256', substr($phone, 0, 3), config('app.key')) - 需要按身份证号归属地筛选？提取地址码（前 6 位）存为明文
id_card_area_code - 绝对不要在加密字段上建索引，MySQL 会索引整个密文，毫无意义且拖慢写入
加解密不是开关，是权衡。密文字段只能用于展示和精确匹配（比如登录时比对加密后的密码），其他一切操作都要提前规划替代路径。漏掉这点，后期改起来比重写还疼。
