ThinkPHP Cookie加密需显式启用auto_encrypt并配置合规secret_key，否则数据明文存储；安全属性如httponly、secure依赖正确配置与响应头发出，且加密不防篡改，关键校验必须服务端完成。
cookie() 函数和 Cookie::set() 是 ThinkPHP 操作 Cookie 的核心入口，但直接调用不等于安全可用——加密是否生效、httponly 是否真正写入、secure 在 HTTPS 环境下是否被忽略，全取决于配置项是否对齐框架底层逻辑。
ThinkPHP 的 Cookie 加密不是“开箱即用”，必须显式启用并配密钥
框架默认不加密 Cookie 数据，即使你用了 cookie('token', $val)，值也是明文存进浏览器的。要激活自动加解密，必须在配置中明确开启：'auto_encrypt' => true，并提供长度足够（推荐 32 字节以上）的 'secret_key'。
常见错误现象：
- 配置写了
auto_encrypt => true，但没设secret_key→ 加密流程跳过，无报错，数据仍明文 -
secret_key太短（如 8 位字符串）或含不可见字符 →openssl_encrypt报错，导致整个 Cookie 写入失败，$_COOKIE里也收不到 - 部署时 config 缓存未更新 → 本地开发加密正常，线上仍走明文路径
正确做法：
- 在
config/app.php或环境配置文件中统一设置：
'cookie' => [
'prefix' => 'tp_',
'expire' => 0,
'path' => '/',
'domain' => '',
'secure' => true,
'httponly' => true,
'samesite' => 'Strict',
'auto_encrypt'=> true,
'secret_key' => 'your_32_byte_secret_key_here_123456789012', // 必须与 openssl_encrypt 兼容
],
注意：secret_key 不是随便 base64_encode 一下就行，它会被直接传给 openssl_encrypt($data, 'AES-256-CBC', $key)，所以必须是合法密钥长度（16/24/32 字节）。用 random_bytes(32) 生成最稳妥。
立即学习“PHP免费学习笔记（深入）”；
setcookie() 和 Cookie::set() 的行为差异会影响安全属性落地
ThinkPHP 底层仍依赖 PHP 原生 setcookie() 发送响应头，但门面类做了封装。关键区别在于：门面方法（Cookie::set()）会自动合并全局配置 + 当前调用参数；而函数式调用（cookie()）若传了选项数组，会覆盖部分全局配置，但不会自动补全缺失的安全字段。
容易踩的坑：
- 用
cookie('user_id', 123, ['expire' => 3600])→ 覆盖了expire，但httponly、secure等全丢失，等同于没设 - 用
Cookie::set('cart', $data, ['path' => '/shop'])→path被覆盖，但其他安全配置仍从全局继承，更可靠 - 手动调用
setcookie()绕过框架 → 完全脱离auto_encrypt流程，加密失效
建议始终优先使用 Cookie::set()，尤其涉及敏感数据时：
use think\facade\Cookie;
Cookie::set('auth_token', $token, [
'expire' => 7200,
'path' => '/api',
'domain' => '.example.com',
'samesite' => 'Lax',
]);
这样能确保 httponly、secure 等由配置兜底，且加密逻辑完整参与。
加密后 Cookie 值被篡改？框架不校验 HMAC，得自己补
ThinkPHP 的 auto_encrypt 只做 AES 对称加解密，不附带签名（HMAC）。这意味着攻击者截获加密后的 Cookie 值，哪怕无法解密，也能原样重放或拼接旧密文提交——框架照常解密并信任结果。
这不是 bug，是设计取舍：框架聚焦通用性，完整性校验需业务层决定。
如果你需要防篡改（比如存储用户角色、权限标识），不能只靠 auto_encrypt：
- 方案一：在加密前先用
hash_hmac('sha256', $raw_data, $secret_key)算签名，拼成$raw_data . '|' . $hmac再加密；解密后拆分并重验 - 方案二：弃用
auto_encrypt，完全自定义Cookie::set()行为，通过中间件或基类统一注入签名逻辑 - 方案三：敏感状态坚决不用 Cookie 存，改用服务端 Session + 短期 Token 验证，Cookie 只存无意义的 session_id
别把加密当万能锁——它防偷看，不防替换。真正关键的判断逻辑（如“是否管理员”）永远要在服务端查数据库或缓存，而不是信任解密出来的 Cookie 字段。
HTTPS 环境下 secure => true 不生效？先确认响应头真发出去了
ThinkPHP 配置了 'secure' => true，但浏览器开发者工具里看到 Cookie 属性栏 Secure 是空的或灰色——大概率不是框架问题，而是 PHP 输出被提前触发。
典型原因：
- PHP 文件开头存在 UTF-8 BOM（尤其 Windows 记事本保存的文件），
xxd app.php | head -1查看是否有ef bb bf - 路由或中间件里有
echo、var_dump、error_log，甚至某处多了一个空行 - Nginx/Apache 没把
$_SERVER['HTTPS']正确透传（反向代理场景常见），导致框架误判非 HTTPS 环境，跳过secure标志
验证方式：
- 打开浏览器 DevTools → Network → 刷一次页 → 找到 HTML 请求 → Response Headers → 搜索
Set-Cookie - 如果看到类似
Set-Cookie: tp_auth=xxx; expires=...; path=/; domain=; secure; HttpOnly; SameSite=Strict，说明成功；否则就是 header 被拦截了
临时调试可在控制器开头加 if (headers_sent($file, $line)) { die("Headers already sent in $file on line $line"); }，快速定位输出源头。
