Laravel怎么做字段加解密_Laravel怎么保护数据库敏感信息【方案】
Laravel模型字段加密应优先使用mutator或casts自动处理,避免控制器手动加解密导致代码冗余;存量数据迁移须用Eloquent逐条处理以确保一致性;加密字段不可用于查询排序,需设计替代索引字段。
Lara vel模型字段加密应优先使用mutator或casts,避免控制器手动加解密;存量数据迁移须用Eloquent逐条处理;加密字段不可用于查询排序,需设计替代索引字段。

关于Lara vel里的字段加解密,很多人一开始就搞混了方向。框架自带的加密能力其实足够应对手机号、身份证号这类敏感字段,根本不需要额外装包。问题的关键从来不是“能不能加解密”,而是“什么时候加、谁来加”。把加解密逻辑锁死在模型的属性访问层,业务代码完全无感,这才是最自然的落点。
最容易踩的坑是什么?就是在控制器里手动调用 encrypt() 再存进数据库,结果后面查出来要么是明文,要么重复加密导致解密失败。必须让框架接管整个生命周期。
用 encrypt() 和 decrypt() 处理模型字段最直接
具体来说,在模型里定义 setPhoneAttribute($value),内部调用 encrypt($value) 后存入 $this->attributes['phone'];再定义 getPhoneAttribute($value),对 decrypt($value) 结果做空值判断,避免解密失败直接抛异常。需要注意,数据库字段类型必须设为 TEXT——AES加密后是base64字符串,长度远超原始值。另外,别给加密字段加 fillable 或 casts,mutator 会绕过它们。
用 casts 配合自定义 Cast 类更可控
当多个字段要加密,或者需要差异化处理时,硬写 mutator 会越来越难维护。Lara vel 7+ 推荐的路径是 casts + 自定义 Cast 类,把加解密封装成可复用、可测试的单元。这里有一个容易忽视的细节: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(...)")。Lara vel 的加密密钥和 IV 机制与 MySQL 内置 AES 函数完全不兼容,硬套会导致全部数据变废。真正可行的方式只有一种:用 Eloquent 逐条读取 → 解密(如果是旧加密)→ 重新加密 → 保存。虽然慢,但这是唯一能保证密钥、填充方式、序列化格式一致的办法。
- 写一个 Artisan 命令,用
chunkById(100)分批处理,避免内存溢出 - 对每条记录,先用
$model->setAttribute('phone', $model->phone)触发 mutator 或 cast - 显式调用
$model->sa veQuietly()避免触发事件和验证干扰 - 加日志记录失败 ID,方便断点续跑
加密字段无法用于 where 查询或排序
这是加密的必然代价:密文不可预测、不可比较。你没法写 where('phone', 'like', '%138%'),也没法 orderBy('id_card')。任何想“查加密字段”的需求,本质都是设计缺陷。真实场景里,搜索敏感信息几乎都靠关联脱敏标识,或者引入单独的索引字段。
- 需要模糊搜索手机号?存一个
phone_prefix_hash字段,值为hash_hmac('sha256', substr($phone, 0, 3), config('app.key')) - 需要按身份证号归属地筛选?提取地址码(前 6 位)存为明文
id_card_area_code - 绝对不要在加密字段上建索引,MySQL 会索引整个密文,毫无意义且拖慢写入
加解密不是开关,是权衡。密文字段只能用于展示和精确匹配,其他一切操作都要提前规划替代路径。漏掉这点,后期改起来比重写还麻烦。


































