Laravel怎么做字段加解密_Laravel怎么保护数据库敏感信息【方案】

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 会索引整个密文，毫无意义且拖慢写入

加解密不是开关，是权衡。密文字段只能用于展示和精确匹配，其他一切操作都要提前规划替代路径。漏掉这点，后期改起来比重写还麻烦。