php 安全读取 $_cookie 需先用 isset()或 array_key_exists()检查键存在，再过滤值；setcookie()后当前请求无法立即读取新值；filter_input()可简化过滤但需显式指定过滤器；secure cookie 在 http 下不可见。
PHP 怎么安全读取 $_COOKIE 里的值
直接用 $_COOKIE['key'] 会报 Undefined index 警告，而且可能被恶意篡改。必须先检查键是否存在、再过滤内容。
- 永远用
isset($_COOKIE['user_id'])或array_key_exists('user_id', $_COOKIE)判断，别直接下标访问 - 读到的值是字符串，且未经任何校验——比如
$_COOKIE['theme']可能是"dark<script>alert(1)</script>"，不能直接输出到 HTML - 如果用于数据库查询或文件路径拼接，必须额外过滤：
intval($_COOKIE['page'])或basename($_COOKIE['lang']) - 注意：PHP 8.1+ 对未定义
$_COOKIE键的访问会触发E_WARNING，不是静默null
为什么 setcookie() 后立刻读不到新值
因为 $_COOKIE 只在请求开始时从 HTTP 头解析一次，setcookie()只是告诉浏览器“下次请求带上这个”，当前脚本里不会自动更新 $_COOKIE 数组。
- 刚调用
setcookie('token', 'abc')，紧接着echo $_COOKIE['token']还是旧值（或报错），这是正常行为 - 想立刻拿到新值？只能手动赋值：
$_COOKIE['token'] = 'abc';（仅限调试，生产环境不推荐） - 更稳妥的做法是：把要写入 cookie 的数据先存进变量，后续逻辑统一用该变量，而不是反复读
$_COOKIE
$_COOKIE和 filter_input(INPUT_COOKIE, ……) 有啥区别
后者是带过滤能力的读取方式，能省掉手动 isset() 和htmlspecialchars()两步，但默认不过滤，得显式指定过滤器。
-
filter_input(INPUT_COOKIE, 'email', FILTER_SANITIZE_EMAIL)会自动处理不存在的键（返回false或null），不用包isset() - 但注意：
FILTER_SANITIZE_EMAIL只删非法字符，不验证邮箱格式；真要校验得用FILTER_VALIDATE_EMAIL - 性能上几乎没差别，但
filter_input可统一管理输入源（GET/POST/COOKIE），适合中大型项目 - 陷阱：如果 cookie 值是
"123abc"，用FILTER_SANITIZE_NUMBER_INT会得到"123"——截断不报错，容易漏数据
HTTPS 环境下读Secure cookie 失败怎么办
非 HTTPS 请求里，浏览器根本不会发送标记了 Secure 的 cookie，所以 $_COOKIE 里自然没有它——这不是 PHP 问题，是协议强制限制。
立即学习“PHP 免费学习笔记（深入）”；
- 开发时用 HTTP 本地测试却设置了
setcookie('sess', $v, ['secure' => true])，会导致读不到，去掉secure或改用$_SERVER['HTTPS'] === 'on'动态判断 -
HttpOnly不影响 PHP 读取，只防 JS 访问；但SameSite=Strict在跨站跳转时也会让 cookie 不携带，导致读空 - 调试技巧：用浏览器开发者工具的 Application → Cookies 面板确认 cookie 是否真的存在、属性是否符合预期，别只盯着 PHP 代码猜
最常被忽略的是：cookie 值始终是用户可控的字符串，哪怕你用 hash_hmac() 签过名，也要在读取后重新校验签名，否则伪造值可以直接绕过所有逻辑判断。
