ThinkPHP 5.1 移除了 cookie.encrypt 配置，改由 cookie.salt 控制自动加密（AES-128-CBC），TP6 则默认启用签名+加密双校验，密钥变更将导致旧 Cookie 失效。
ThinkPHP 5.1 的 cookie.encrypt 配置已失效
TP5.1 开始，cookie.encrypt 配置项被移除，不再控制 Cookie 加密开关。它被更底层的加密机制替代：所有写入 Cookie 的值默认经过 think\facade\Cookie 的 set() 方法自动加密（前提是配置了 cookie.salt 且未显式传入 raw=true）。
常见错误现象是：升级到 5.1 后发现 Cookie 看起来“没加密”，其实是你用 setcookie() 或 header('Set-Cookie:...') 手动设置的——这些绕过了框架加密逻辑；或者你在 set() 时加了 ['raw' => true] 参数，主动关闭了编码和加密。
-
cookie.salt必须非空（建议 32 字符以上随机字符串），否则加密退化为 base64 编码 - 加密使用的是 AES-128-CBC，密钥由
cookie.salt和应用密钥app.key混合生成，不可单独替换 salt - 如果需要明文 Cookie（如给前端 JS 读取），必须显式传
['raw' => true, 'httpOnly' => false]，但此时完全不加密、不签名
ThinkPHP 6.x 的 Cookie 类默认启用签名 + 加密双校验
TP6 把 Cookie 安全拆得更细：set() 默认既加密又签名，读取时先验签再解密。签名密钥独立于加密密钥，由 cookie.secret 控制（若未设置，则 fallback 到 app.key）。
典型踩坑点：从 TP5 升级到 TP6 后，旧 Cookie 无法读取。这是因为 TP6 默认开启签名，而 TP5 写入的 Cookie 没有签名字段，get() 会直接返回 null。
立即学习“PHP免费学习笔记（深入）”；
- 兼容旧 Cookie：在配置中设
'cookie' => ['sign' => false]，临时关闭签名验证（仅用于迁移期） - 不要把
cookie.secret设为空字符串，这会导致签名逻辑跳过，但加密仍生效，容易误判为“没起作用” - TP6 中
cookie.raw配置项已废弃，是否 raw 只能靠set()的参数控制
TP5.1 与 TP6 的 cookie.domain 行为差异影响跨子域共享
两者都支持 cookie.domain 配置，但解析逻辑不同：TP5.1 要求必须以 . 开头（如 .example.com），否则不生效；TP6 会自动补前导点，example.com 和 .example.com 效果一致。
实际问题常出现在本地开发：设成 localhost，结果 Chrome 拒绝写入（因不符合 Cookie domain 规范），而 TP5.1 不报错、TP6 在 debug 模式下会抛 InvalidArgumentException 提示 “Invalid cookie domain”。
- 开发环境统一用
127.0.0.1替代localhost，避免 domain 校验失败 - 生产环境务必确认
cookie.domain与实际访问域名严格匹配（大小写敏感、无多余空格） - TP6 中若同时设置了
cookie.secure = true但请求是 HTTP，Cookie 将静默丢弃，不会报错也不会写入
加密密钥轮换时旧 Cookie 失效是设计使然，不是 bug
无论是 TP5.1 还是 TP6，只要 app.key 或 cookie.salt / cookie.secret 发生变更，之前写入的所有加密 Cookie 都无法解密，get() 返回 null。这不是异常，是安全模型的必然结果。
线上遇到“用户集体登出”，第一反应不该是回滚密钥，而是检查部署流程是否意外覆盖了 .env 里的 APP_KEY —— 很多 CI/CD 脚本会重写该文件，导致每次部署密钥都变。
- 密钥必须持久化，不能每次启动都随机生成（如用
Str::random(32)初始化） - 多实例部署时，所有机器必须共用同一套
app.key和cookie.*配置，否则节点间 Cookie 不互通 - 如果真要灰度轮换密钥，需自定义
Cookie组件，实现双密钥解密逻辑（兼容旧密钥解密 + 新密钥加密），但复杂度高，一般不推荐
