cookie有效期设置错误直接破坏会话连续性：过期时间必须为unix时间戳（如time()+3600），而非相对秒数；服务器与客户端时间不同步、缺失secure属性、删除时path/domain不匹配，均导致cookie失效或残留。
Cookie有效期设置错误，直接破坏了用户会话的连续性，不是功能缺陷，而是状态管理逻辑的断裂。浏览器依据你提供的过期时间决定是否发送该Cookie；一旦这个时间出错，服务器就收不到有效凭证，自然判定“用户未登录”，强制跳转回登录页。
过期时间传错：把秒数当时间戳用
这是最普遍的错误。setcookie()第三个参数（或options数组中的expires）必须是Unix时间戳（如1757635200），而非相对秒数。
- ❌ 错误写法：
setcookie('token', 'abc', 3600, '/');—— 浏览器把它当成1970年1月1日之后3600秒（即1970-01-01 01:00:00），远早于当前时间，Cookie立刻失效 - ✅ 正确写法：
$expire = time() + 3600; setcookie('token', 'abc', $expire, '/');—— 明确计算出未来一小时的具体时间点
服务器与客户端时间不同步
Cookie过期判断由浏览器执行，它依赖本地系统时间。如果服务器用time()生成时间戳，但用户电脑时间被手动调快了2小时，那本该7天后过期的Cookie，实际可能3天就消失了。
- 生产环境务必启用NTP服务同步服务器时间
- 避免在关键业务中依赖极长有效期（如1年），建议按需设为7–30天，并配合自动续期逻辑
安全属性缺失导致跨协议失效
若网站已全站HTTPS，但设置Cookie时没加secure标志，HTTP响应头里就不会带Secure属性。结果是：
- 用户通过HTTPS访问时，浏览器因缺少Secure标记拒绝存储该Cookie
- 或旧Cookie在HTTP页面设置后，无法被后续HTTPS请求携带，造成“刚登完就掉线”
- 真实案例中，超80%的莫名登出问题源于此配置遗漏
删除时路径/域名不匹配，旧Cookie顽固残留
想删Cookie，却只改了过期时间，没保持path、domain、secure等参数一致，等于在另一个“抽屉”里放了个过期条，原抽屉里的仍有效。
- 设置时用了
setcookie('user', 'x', time()+86400, '/admin', '.example.com', true, true) - 删除时却写成
setcookie('user', '', time()-1, '/', '', false, false)→ 无效 - 必须严格复用原路径、域名、安全属性，才能精准覆盖
