app_key配置错误是laravel加密失败的绝对主因：必须为32字节、无空格换行的base64字符串，不可手动截断或补全；复制时易混入零宽字符，需用cat -a检查；.env中须完整保留php artisan key:generate生成的base64:前缀密钥，且config/app.php硬编码时应为raw key。
APP_KEY 配置错误是 Laravel 加密失败的绝对主因，不是“没配”，而是配得不对——它必须是 32 字符、无空格、无换行的 base64 编码字符串，且不能手动截断或补全。
APP_KEY 必须是 32 字符，且不能含隐藏字符
运行 php artisan key:generate 后，.env 中的 APP_KEY 值必须完整保留，不能手动删减或添加前缀（如 base64:）。常见问题包括：
- 复制粘贴时带入不可见 Unicode 字符（如零宽空格），可用
cat -A .env查看真实内容 - 编辑器自动换行导致密钥被截断（尤其在 Windows 记事本中）
- 误将
APP_KEY=后面的值写成 24 或 16 字符（对应 AES-128 或旧版要求），Laravel 256-CBC 默认需要 32 字节原始密钥 -
config/app.php中若硬编码'key' => 'xxx'，该字符串必须是 raw key（非 base64 形式），否则Encrypter构造时会因长度校验失败抛出RuntimeException
encrypt() 和 encryptString() 的底层行为差异
两者都走 Encrypter，但输入处理逻辑不同，混用必报 DecryptException: The payload is invalid：
-
Crypt::encrypt($value)：先serialize($value)，再加密；支持数组、对象、null 等任意 PHP 类型；解密后自动unserialize -
Crypt::encryptString($str)：跳过序列化，直接加密原始字符串字节；解密后返回原字符串，无额外解析开销 - 数据库字段若为
TEXT，优先用encryptString；若存的是用户偏好设置等数组，才用encrypt - 切勿对
encryptString的结果调用decrypt，或反之——二者生成的 payload 结构不兼容
解密异常必须按类型区分处理
看到 DecryptException 不要直接重试或忽略，先看异常消息具体内容：
-
The payload is invalid→ 密文被截断、传输损坏，或用了错误的APP_KEY（最常见） -
The MAC is invalid→ 密文完整性遭破坏（如数据库字段被部分更新、URL 参数被未 urlencode 修改），不是密钥问题 - OpenSSL 相关错误（如
openssl_encrypt(): IV passed is only 0 bytes long）→ PHP OpenSSL 扩展未启用，或APP_KEY为空字符串 - CLI 和 Web 请求可能加载不同环境（如
.env.testing），务必确认dd(app()->environment())和实际运行上下文一致
数据库字段和传输场景的实操细节
加密输出是 base64 字符串，含 +、/、=，直接拼进 URL 或存进短字段会出事：
- 存数据库：字段类型必须是
TEXT，VARCHAR(255)肯定不够（32 字节原文加密后 base64 可达 ~44 字符，加上 IV/MAC 后普遍超 300 字符） - 传 HTTP 参数：必须
urlencode()加密结果，接收端先urldecode()再解密 - 敏感字段别塞进模型访问器自动解密：每次
toArray()或日志记录都会触发，且无法避免重复解密；真要用，至少缓存到临时属性 -
APP_KEY泄露 = 所有加密数据裸奔，绝不能进 Git；检查.env是否在.gitignore中，生产环境禁用APP_DEBUG=true
真正麻烦的从来不是怎么调用 encryptString，而是密钥生命周期管理、密文存储边界控制、以及异常发生时能否快速定位是 MAC 失败还是密钥错配——这三处一错，解密就变成黑盒调试。
