Laravel强制加密签名所有Cookie，$_COOKIE读取的是未解密未校验的base64密文，必须用$request->cookie()安全读取，否则返回null；默认全量加密，仅显式列入$except的非敏感Cookie（如_ga）才不加密。
不能直接查看 Laravel Cookie 中加密存储的明文内容——这不是操作限制，而是安全设计的必然结果。框架强制对绝大多数 Cookie 执行 AES-256-CBC 加密 + HMAC 签名，原始值（如 "user_id:123"）会被转换为包含 iv、value、mac 的 JSON 结构，再经 base64 编码，形如 eyJpdiI6ImZv...。浏览器开发者工具里看到的，就是这一串不可读的密文。
为什么不能在浏览器或 $_COOKIE 里“解出来”
直接读 $_COOKIE['name'] 拿到的是未解密、未校验的原始字符串，它不是“加密后还能手动还原的数据”，而是一段必须由 Laravel 内部流程处理的结构化密文。跳过签名验证就解密，等于放弃防篡改能力；而手动调用 Crypt::decrypt() 也行不通，因为：
- Laravel 使用的 IV（初始化向量）是随机生成且随每次写入变化的，不保存在服务端，只和密文一起传给客户端
- MAC（消息认证码）依赖 APP_KEY 和完整密文计算，缺一不可；篡改任意字节都会导致 MAC 校验失败
- 框架默认启用序列化（
$serialize = true），写入数组或对象时还会额外套一层 PHP 序列化，不是纯字符串加解密
唯一安全可靠的读取方式：request()->cookie()
这是 Laravel 唯一暴露给开发者的、经过完整验证链的读取入口。它内部自动完成：解析 base64 → 提取 iv/value/mac → 校验 MAC → 解密 value → 反序列化（如需）→ 返回原始 PHP 值。整个过程静默失败：校验不通过、APP_KEY 错误、Cookie 过期，都只返回 null，不抛异常、不报错、不记录日志（除非 debug 模式开启并监听 CookieDecryptionException）。
示例：
// 控制器中
public function index(Request $request)
{
$token = $request->cookie('auth_token'); // ✅ 正确：返回解密后的真实字符串或 null
$theme = $request->cookie('theme', 'light'); // ✅ 支持默认值
}
调试时想确认内容？用日志+可控环境
生产环境绝不应输出 Cookie 明文。若在本地开发或测试中需要验证写入是否符合预期，推荐以下方式：
- 在写入 Cookie 后，立即用
$request->cookie()读取并Log::debug()记录，确保服务端视角逻辑正确 - 在 PHPUnit 测试中使用
$this->withCookie('name', 'raw_value')手动注入未加密值（需先在EncryptCookies::$except中临时排除该名），用于模拟边界场景 - 检查
.env中的APP_KEY是否一致——换环境未重置 key 是旧 Cookie 全部失效的最常见原因
哪些 Cookie 默认不加密？别误加进 except
EncryptCookies 中央配置决定加密范围：默认 $except = []，即“全量加密”。你只能显式列出**完全不需要框架保护**的名称，例如：
- 第三方统计 Cookie：
'_ga'、'_gid' - CDN 或反向代理标识：
'AKA_A2'、'CloudFront-Policy' - 纯前端功能标记：
'tour_shown'、'consent_given'
切勿把 laravel_session、remember_web_*、XSRF-TOKEN 加入 $except——它们深度依赖加密签名机制，绕过即等于关闭安全层。例外列表不支持通配符，'XSRF-*' 无效，必须写全名。
