是的，ThinkPHP 5.1+ 默认开启 Cookie 签名机制，自动对 cookie() 写入值签名并校验，但仅保护值不保护键名，且不覆盖原生 $_COOKIE 或 setcookie()；禁用需显式设 'sign' => false。
ThinkPHP 的 Cookie 签名机制默认开启吗？
是的，ThinkPHP 5.1+ 默认对 cookie() 写入的值自动签名，读取时会校验签名一致性。这意味着直接篡改 Cookie 值（如修改 user_id=123 为 user_id=999）会导致 cookie('user_id') 返回 null 或抛出异常（取决于配置），而不是错误地信任恶意值。
但这个保护只作用于通过 cookie() 函数写入/读取的值；如果绕过该函数、用原生 $_COOKIE 访问，或手动调用 setcookie()，签名机制完全失效。
- 签名密钥来自应用配置中的
cookie.salt（TP6 中为cookie.encrypt_key），若未显式设置，框架会自动生成，但不建议依赖默认值 - 签名仅覆盖值本身，不保护键名（
key）——攻击者仍可伪造任意键名，只要值签名无效，框架就忽略它 - 禁用签名需显式设置
'sign' => false，但生产环境绝不推荐
哪些 Cookie 场景必须手动转义？
签名防篡改 ≠ 防 XSS 或 SQL 注入。当 Cookie 值被输出到 HTML、拼接到 SQL、或用于文件路径时，仍需按上下文做对应转义。
典型高危场景：
立即学习“PHP免费学习笔记（深入）”；
- 将
cookie('nickname')直接 echo 到页面：<div><?= cookie('nickname') ?></div>→ 必须用htmlspecialchars()转义 - 用
cookie('token')拼接 SQL 查询："SELECT * FROM user WHERE token = '" . cookie('token') . "'"→ 必须用参数绑定，或至少addslashes()（但不推荐） - 将
cookie('lang')作为文件名的一部分：include 'lang/' . cookie('lang') . '.php'→ 必须白名单校验或basename()过滤
ThinkPHP 不会对读取后的 Cookie 值自动转义——它只负责“你给的值没被改过”，不负责“你拿它干啥”。这点常被忽略。
如何验证 Cookie 是否真的被篡改？
不要只依赖 cookie('xxx') === null 判断失效，因为某些配置下签名失败可能返回空字符串或原始值（尤其在调试模式或 app_debug=true 时）。
可靠做法是显式检查签名状态：
// TP6 示例：使用 Cookie 组件的 verify 方法
use think\facade\Cookie;
if (!Cookie::has('user_id') || Cookie::get('user_id', '', false) === null) {
// 签名校验失败，视为非法
abort(403, 'Invalid cookie');
}关键点：
- 第三个参数
false表示“不尝试自动修复或降级”，强制校验签名 -
Cookie::has()只检查是否存在，不校验签名；必须配合get(..., '', false)才能确认有效性 - 若业务允许部分降级（如旧版 Cookie 兼容），需单独处理，但新项目应拒绝所有未签名/签名失败的值
加密 Cookie 和签名 Cookie 有什么区别？
ThinkPHP 默认只签名，不加密。签名保证“值没被改”，但不隐藏“值是什么”——抓包就能看到明文 Cookie。
如需保密（例如存储临时 token、用户偏好等敏感但非凭证类信息），需启用加密：
- TP6 中设置
'encrypt' => true并配置cookie.encrypt_key（必须为 32 字节随机字符串） - 加密后，
cookie('data')写入和读取自动加解密，且仍保留签名校验 - 注意：加密不解决输出上下文安全问题，HTML 输出仍需
htmlspecialchars() - 性能影响轻微，但服务端解密失败时行为与签名失败一致（返回 null）
加密不是银弹。真正敏感数据（密码、JWT 私钥、数据库凭证）永远不该进 Cookie —— 这个边界比技术配置更重要。
