Hash::make()仅用于密码哈希，不可逆；需加解密时用Crypt::encryptString()/decryptString()，确保APP_KEY一致且安全配置。
Hash::make() 适合存密码，不适合加密字符串
很多人一看到 Hash 就想拿来“加密”普通文本，结果发现根本解不开——因为 Hash::make() 是单向散列，不是加密。它用的是 bcrypt（或 argon2），设计目标就是不可逆，专为密码存储而生。
常见错误现象：Hash::make('hello') 得到一串哈希值，但没有任何 Laravel 内置方法能把它变回 'hello'；有人试图用 Hash::check() 反向穷举，这既不现实也不安全。
- 只在用户注册/改密时对明文密码调用
Hash::make() - 验证时用
Hash::check($input, $hashed)，别试图“解密” - 如果业务需要加解密（比如加密 URL 参数、数据库敏感字段），必须换
Crypt
Crypt::encryptString() 和 Crypt::decryptString() 是当前推荐方式
Laravel 9+ 默认禁用了 Crypt::encrypt() / decrypt()（它们操作 PHP 数组和序列化数据，有反序列化风险），转而主推 Crypt::encryptString() 和 Crypt::decryptString()。这两个函数只处理字符串，更安全、语义更清晰。
使用场景：加密 API token、临时凭证、数据库中 email 字段（需搜索时慎用，加密后无法模糊查询）。
- 加密前确保
APP_KEY已正确配置且未泄露（它就是 AES 密钥） -
Crypt::encryptString('secret123')返回 base64 编码的加密字符串，可直接存 DB 或传前端 - 解密失败会抛出
Illuminate\Contracts\Encryption\DecryptException，必须 try/catch - 不要在日志里打印加密结果——base64 看似无害，但可能被重放或误用
解密失败常见原因：APP_KEY 不一致或数据被篡改
最典型的报错是 DecryptException: The payload is invalid.。这不是代码写错了，而是加密上下文断了。
性能影响很小，AES-GCM 加解密本身很快，瓶颈通常在 PHP OpenSSL 扩展是否启用，以及 APP_KEY 长度是否合规（Laravel 要求 32 字符，对应 AES-256）。
- 检查
APP_KEY在所有环境（本地、测试、生产）是否完全一致（注意空格和换行） - 确认加密和解密用的是同一个 Laravel 应用实例，跨应用解密需共享密钥且版本兼容
- 避免手动修改加密后的字符串（比如 URL 中截断、JSON 里误加转义）
- 如果用队列任务解密，确保任务执行时的
APP_KEY没被覆盖（比如通过 env 动态加载出错）
别把 Crypt 当数据库字段加密方案来用
直接对 DB 字段（如 users.phone）全量加密听起来很安全，但实际会破坏查询能力、索引效率和关联逻辑。
例如：你无法用 WHERE phone = ? 查加密值，也不能对加密字段建有效索引；JOIN 时若两边加密方式不一致，关联就失效。
- 优先考虑字段级权限控制（Policies）、视图层脱敏、或数据库原生加密（如 MySQL
AES_ENCRYPT） - 如果必须应用层加密，只加密真正需要隔离的字段（如身份证号），并接受它不可搜索
- 加密前考虑是否要保留格式（如手机号掩码显示），这时候可能只需
substr_replace()而非全量加密
Hash；字符串要可还原，用 Crypt::encryptString()。而 APP_KEY 的一致性，往往比代码逻辑更早决定成败。 
