Crypt::encryptString()仅支持字符串，加密GET数组参数需先json_encode()再加密，解密时须严格按urldecode()→decryptString()→json_decode()顺序执行，且不可在模型访问器中处理。
直接用 Crypt::encryptString() 加密 GET 数组参数不可行——它只接受字符串，传数组会报错或序列化后产生不可靠的 base64 字符串，前端拼接 URL 时容易被截断或编码破坏。必须先序列化再加密，且解密端要严格还原步骤。
GET 参数加密前必须手动序列化
Laravel 的 Crypt::encryptString() 不接受数组，Crypt::encrypt() 虽能处理数组，但会自动 serialize() + 加密，生成的字符串含 PHP 特有结构（如 a:2:{s:4:"id";i:1;s:5:"token";s:10:"abc123..."}），经 URL 编码后可能被中间件、代理或浏览器误处理（比如丢掉 {、; 或空格）。
- 安全做法：用
json_encode($array)转成标准 JSON 字符串，再传给Crypt::encryptString() - 避免用
http_build_query()—— 它生成的key=value&key2=value2格式无结构，解密后还得手动解析，且等号、& 符号在 URL 中需额外编码 - 加密后必须
urlencode()再拼入 URL，否则 +、/、= 等字符会被 URL 解析器误读
解密时先 urldecode 再 json_decode
GET 请求中拿到的加密参数是经过 URL 编码的，直接传给 Crypt::decryptString() 会因字符损坏抛 DecryptException: The payload is invalid。
- 顺序不能错：
urldecode()→Crypt::decryptString()→json_decode($str, true) - 必须检查
json_decode()返回值是否为null（可能是 JSON 解析失败，或解密后内容为空） - 不要依赖
request()->query('param')自动解码 —— 某些环境（如 Nginx 配置不当）可能未正确解码，建议显式调用urldecode()
为什么不能在模型访问器里做 GET 参数解密
get***Attribute 是为数据库字段设计的，它在 toArray()、API 响应、日志序列化时都会触发。GET 参数是临时请求数据，不属于模型属性，硬塞进访问器会导致：
- 每次调用
$request->all()或打印请求时都尝试解密，增加不必要的开销和异常风险 - 如果参数缺失或损坏，访问器抛异常会中断整个请求生命周期
- 无法控制解密上下文（比如不同路由需要不同密钥或超时逻辑）
正确位置是控制器方法开头，或封装成独立的 RequestDecrypter 工具类，明确输入输出边界。
APP_KEY 变更会导致所有历史 GET 参数失效
GET 参数加密值绑定当前 APP_KEY，一旦执行 php artisan key:generate，所有之前生成的加密链接立即失效，用户点击会直接 500 或白屏。
- 短时效场景（如一次性下载链接）可接受；长期有效的链接（如邮件中的重置链接）必须配独立密钥管理，或改用
Hash::make()+ 数据库比对 - 不要把加密 GET 参数用于身份认证主链路——它缺乏防重放、时效校验，仅适合轻量级参数混淆
- 若必须支持密钥轮换，得在解密逻辑里 fallback 到旧 key 尝试，且旧 key 必须安全存档（不能硬编码在代码里）
真正麻烦的不是怎么写那几行加密代码，而是 URL 里混入加密字符串后，你得同时对付编码、传输、缓存、CDN 和浏览器兼容性——每个环节都可能悄悄吃掉几个字符，让最终解密失败。
