应统一使用cookie()助手函数设置和读取值：cookie('key', 'val', 3600)设值，cookie('key')读值，cookie('?key')判断存在，cookie('key', null)删除，cookie(null)清空当前前缀下所有Cookie。
Cookie 在 ThinkPHP5 中不是直接操作 $_COOKIE 或原生 setcookie()，而是通过封装好的门面类或助手函数统一管理，底层自动处理前缀、加密、路径、域等细节。只要配置得当，读写删基本不会出错；但一旦混淆了「助手函数」和「门面类」的参数规则，或忽略配置项影响，就会出现设了读不到、删不干净、跨子域失效等问题。
怎么用 cookie() 函数设置和读取值
cookie() 是最常用的方式，简洁且兼容性好，适合控制器、模型、视图中快速使用。它本质是助手函数，会自动识别当前 Cookie 配置（比如前缀、加密开关）。
- 设置：直接传值和过期时间，如
cookie('token', 'abc123', 7200)表示存 2 小时 - 读取：
cookie('token')返回值，不存在则返回null - 判断是否存在：
cookie('?token')返回布尔值 - 删除：把值设为
null，即cookie('token', null) - 清空全部（当前前缀下）：
cookie(null)
注意：如果配置了前缀（如 prefix => 'tp5_'），cookie('user') 实际操作的是 tp5_user 这个键名，浏览器 DevTools 里看到的也是带前缀的名称。别手动拼接前缀再调用，否则会写重或读空。
为什么 Cookie::set() 有时设不成功
Cookie::set() 是门面类方法，参数签名和 cookie() 不同，容易踩坑：
- 它不接受整数作为第三个参数表示过期秒数，必须传数组选项，例如：
Cookie::set('name', 'val', ['expire' => 3600]) - 若误写成
Cookie::set('name', 'val', 3600)，TP5 会把3600当作prefix参数，导致实际写入的 key 变成3600_name，读的时候自然找不到 - 同样，
Cookie::get('name')默认使用全局配置的前缀，但如果你在config/cookie.php里改过prefix，而没同步更新代码逻辑，也会读空
建议：除非需要动态覆盖配置（比如临时换前缀），否则统一用 cookie() 函数，更直观、容错更强。
删除和清空 Cookie 的几种方式及区别
删除动作看似简单，但不同调用方式作用范围不同，尤其在多前缀、多域名场景下极易误操作：-
cookie('name', null)：只删名为name的 Cookie（按当前前缀解析后的真实名） -
Cookie::delete('name')：效果同上，但同样受前缀影响；若传第二个参数如Cookie::delete('name', 'tp5_')，则强制按该前缀删 -
cookie(null)：清空当前配置前缀下的所有 Cookie（不含其他前缀） -
Cookie::clear()：等价于cookie(null) -
Cookie::clear('tp5_')：清空指定前缀的所有 Cookie
关键点：清空操作不会跨前缀生效。比如你用 cookie(['prefix' => 'api<em>'])</em> 初始化过一次，之后调 cookie(null) 只清 api*，原来默认前缀的仍保留。
立即学习“PHP免费学习笔记（深入）”；
加密和安全配置对读写的影响
ThinkPHP5 默认开启 Cookie 自动加密（依赖config/cookie.php 中的 auto_encrypt 和 secret_key），这带来两个现实问题：
- 如果你用
$_COOKIE['name']直接读取，拿到的是加密后的乱码，不是原始值 —— 必须走cookie('name')或Cookie::get('name')才会自动解密 - 换密钥或关掉
auto_encrypt后，旧 Cookie 全部失效，用户会“登出”—— 这不是 bug，是设计行为
另外几个常被忽略的安全配置项：
-
httponly => true：禁止 JS 访问，防 XSS 窃取，但意味着前端无法用document.cookie操作它 -
secure => true：仅 HTTPS 下发送，本地开发用http://时设为false，否则 Cookie 写不进浏览器 -
samesite => 'Strict'或'Lax'：影响跨站请求是否携带 Cookie，调试 OAuth 或 iframe 场景时需特别留意
这些配置一旦写死在 config/cookie.php 里，就会影响所有 cookie() 和 Cookie::* 调用，改之前最好确认环境一致性。
真正麻烦的不是语法，而是前缀、加密、路径、域、安全标志这几层叠加后产生的隐式行为。哪怕只是改了一个 prefix，也可能让登录态在二级域名间突然中断，或者让测试环境的 Cookie 在生产环境里被拒绝读取。动手前先看一眼 config/cookie.php，比查文档更快定位问题。
