laravel 的 encrypt() 和 decrypt() 基于 aes-256-cbc 对称加密，依赖 app_key；需注意 base64 长度、url 编码、数据库字段类型（推荐 text）、异常捕获、禁止模型自动加密、app_key 严防泄露、密码应哈希而非加密。
用 encrypt() 和 decrypt() 最快上手
Laravel 自带的加密解密不是靠自己写算法，而是基于 OpenSSL 和 APP_KEY 做的对称加密（AES-256-CBC），默认就开箱即用。只要 APP_KEY 没被重置过，加密后的字符串就能稳定解回来。
常见错误是把加密结果当普通字符串直接存进数据库却不注意长度——encrypt() 输出的是 base64 编码，比原文长约 33%，且含 +、/、=，存进 URL 或某些数据库字段（比如 VARCHAR(255)）容易截断或出错。
- 加密前先
trim()输入值，避免前后空格导致解密后多出空白 - 数据库字段建议用
TEXT类型，别卡在VARCHAR(255) - 如果要用于 URL 参数，必须
urlencode()加密结果，解密前先urldecode() -
decrypt()失败会抛出Illuminate\Contracts\Encryption\DecryptException，务必 try-catch，不能假设一定成功
示例：
use Illuminate\Support\Facades\Crypt;
$encrypted = Crypt::encrypt('api_key_abc123'); // 返回一长串 base64 字符串
$decrypted = Crypt::decrypt($encrypted); // 得到 'api_key_abc123'
别在模型里自动加密字段（除非你真需要）
很多人一上来就想给 $casts 加个 'api_token' => 'encrypted'，但 Laravel 官方不支持这种 cast 类型。硬写访问器/修改器看似方便，实则埋坑：搜索失效、Eloquent 查询无法下推到 SQL、JSON 序列化行为异常。
真正需要“透明加解密”的场景极少。多数时候你只是想存敏感值，又不想裸奔——那就手动控制时机更安全。
- 写入时调用
Crypt::encrypt($value)，读取时再Crypt::decrypt($value) - 不要在
get***Attribute里做解密，否则每次toArray()或 API 返回都触发，还可能被序列化进日志 - 如果必须用访问器，至少加缓存：解密结果存在临时属性里，避免重复解密
- 注意：
where()查询不能直接查加密字段内容，得先解密再比对，或者改用哈希（如密码场景）
APP_KEY 泄露 = 所有加密数据裸奔
这是最容易被忽略的致命点：APP_KEY 不是密码，它等同于加密密钥。一旦泄露，攻击者拿走数据库里的加密字段，分分钟全部解出来。
- 绝不能把
APP_KEY提交到 Git，检查.env是否在.gitignore里 - 不同环境（本地 / 测试 / 生产）必须用不同
APP_KEY，生产环境的 key 绝不能复用本地生成的 - 重置
APP_KEY后，所有已加密数据将无法解密——没有回滚机制，提前评估影响范围 - 如果业务要求更高安全性（比如金融级），别依赖
Crypt，该上 KMS 或硬件加密模块
加密 vs 哈希：别把密码当敏感配置来加解密
加密是双向的，适合 API 密钥、第三方 token 这类“之后还要原样用”的数据；而密码、主账号凭证这类，必须用单向哈希（Hash::make()），永远不该能被解出来。
- 用户密码走
Hash::make()+Hash::check()，不是Crypt::encrypt() - API 密钥、支付私钥、数据库连接串中的密码——这些才是
Crypt的合理使用场景 - 别为了“统一”把所有敏感字段都加密，有些字段其实只需脱敏展示（如手机号中间四位打 *），根本不用碰加密
- 如果字段要频繁参与比较（如校验 token 是否有效），优先考虑签名（
JWT）或短期有效的哈希，而不是每次解密
事情说清了就结束。加密本身不难，难的是想清楚“谁需要看、什么时候看、看完了怎么防泄漏”。
