setcookie 必须在任何输出前调用，因其依赖 HTTP 响应头；一旦有空格、换行、echo 或 BOM 等隐式输出，即失败且仅报 Warning。
setcookie 函数必须在任何输出之前调用
PHP 的 setcookie 是一个“头信息发送”操作，底层依赖 HTTP 响应头。一旦有哪怕一个空格、换行或 echo 输出，PHP 就会提前发送响应头，此时再调用 setcookie 会直接失败，且默认不报错——只在错误日志里记一条 Warning: Cannot modify header information。
常见踩坑点：
- 文件开头有 UTF-8 BOM（尤其 Windows 编辑器保存时容易带），导致隐式输出
-
require或include的文件末尾有多余空行 - 调试时写了
var_dump($x);但没删干净 - 使用了短标签
且配置未开启，PHP 把它当纯文本输出了
实操建议：开发阶段打开 error_reporting(E_ALL) 和 display_errors=On，配合查看错误日志；上线前用 headers_sent() 检查是否还能发 cookie：
if (headers_sent($file, $line)) {
error_log("Cannot set cookie: headers already sent in $file on line $line");
}domain 和 path 参数不填就等于当前域名+当前路径
很多人以为不传 domain 就是“全站可用”，其实不是：setcookie('name', 'val') 中的 domain 默认为当前请求的 Host（比如 user.example.com），不会自动向上匹配 example.com；path 默认是当前脚本所在目录（比如 /admin/login.php 下默认 path='/admin/'），不是 /。
立即学习“PHP免费学习笔记（深入）”；
这意味着：
- 登录后跳转到
/dashboard/却读不到 cookie？很可能是path没设成'/' - 子域间（
api.example.com和www.example.com）想共享 cookie，必须显式设domain='.example.com'（注意开头的点） - 设了
domain='.localhost'在现代浏览器里会被拒绝——localhost不被视作“有效域名”，本地开发建议用127.0.0.1或 hosts 绑定真实域名
secure 和 httponly 不是可选项，而是安全底线
这两个参数控制 cookie 的传输和访问权限，不设≠默认关闭，而是默认“不启用”。线上环境漏掉它们，等于把 session ID 明文暴露在 HTTP 流量里，或让 XSS 脚本能轻易盗取。
关键事实：
-
secure=true表示只通过 HTTPS 发送，HTTP 请求下该 cookie 根本不会出现在请求头中 -
httponly=true表示 JS 无法通过document.cookie读取，能防基础 XSS 窃取 - PHP 7.3+ 开始，
setcookie第 7 个参数支持array('secure'=>true, 'httponly'=>true)，比老式位置参数更清晰 - 如果用了反向代理（如 Nginx），且 PHP 运行在 HTTP 后端，需手动判断
$_SERVER['HTTPS'] === 'on'或检查$_SERVER['HTTP_X_FORWARDED_PROTO']再决定是否设secure
过期时间用 time() + 秒数，别用字符串或 strtotime 的模糊表达
setcookie 的 expires 参数必须是 Unix 时间戳（整型秒数），不是字符串日期，也不是相对描述。写成 strtotime('+1 hour') 看似方便，但容易因时区、夏令时或服务器时间不准出错。
更稳妥的做法：
- 用
time() + 3600明确表示“现在起一小时后” - 设为 0 或省略，表示“会话级 cookie”，浏览器关掉就失效（注意：不是所有浏览器都严格遵守，移动端可能延长）
- 想立刻删除 cookie？不是设空值，而是传一个过去的时间戳：
setcookie('name', '', time() - 3600) - 注意：PHP 的
time()返回的是服务器本地时间，确保服务器时区正确（date_default_timezone_set('Asia/Shanghai')）
复杂点在于：cookie 生效有延迟，设置后当前请求还读不到新值，要等下次请求才生效；而删除操作也得等浏览器下次发请求时才真正丢弃——这些行为不是 bug，是 HTTP 协议本身的设计。
