cookie被提前清除的主因是时间标准不一致：服务器时间不准或时区错误导致生成过期时间已失效；用户本地时间被修改影响浏览器判断；path/domain不匹配致cookie未发送；secure属性在http下静默失效。
Cookie设置了过期时间却仍被浏览器提前清除，不是代码写错了，而是多个环节的时间判断和行为逻辑在“打架”。核心问题不在设置本身，而在“谁按什么时间标准来判定过期”。
服务器时间不准，Cookie一出生就过期
setcookie()或框架（如ThinkPHP的Cookie::forever）依赖服务器当前时间生成未来时间戳。若服务器系统时间慢于真实时间，或PHP时区未正确设置（比如没调用date_default_timezone_set('Asia/Shanghai')），算出来的过期时间可能已是过去时刻。浏览器收到后直接标记为失效，立刻丢弃。
- 用date -R或php -r "echo date('c');"检查服务器时间是否准确、时区是否匹配业务所在地
- 避免硬编码时间字符串，始终用time() + 秒数生成时间戳
- 生产环境建议启用NTP服务自动校时
浏览器本地时间被手动改过
浏览器完全依据用户设备的系统时间判断Cookie是否过期。如果用户把电脑时间调快了几天，原本24小时后才过期的Cookie，可能下一秒就被视为“已过期”；反过来，若把时间调回过去，已过期的Cookie反而能继续用——这会导致测试结果反复无常。
- 开发调试阶段留意用户是否开启了“自动设置时间”功能
- 无法从服务端规避此问题，但可在关键操作前用JS比对服务器时间与客户端时间差，提示异常
路径（path）或域名（domain）不匹配
Cookie不是设了就全局生效。它只会在请求URL路径符合path、且主机名匹配domain时才会被浏览器自动带上。如果设置时用了path='/admin'，但后续请求发到了/api/user，浏览器根本不会发送该Cookie——看起来像“消失了”，其实是压根没发出去。
- 开发期统一设path='/'确保全站可读
- 跨子域共享需显式指定domain='.example.com'（注意开头的点）
- 检查开发者工具Application → Cookies里显示的Path/Domain字段是否与请求地址一致
安全属性（secure/httponly）触发静默拦截
当secure=true时，Cookie仅在HTTPS下传输。若你在HTTP协议下测试（比如localhost未配HTTPS），浏览器会拒绝保存，也不报错——看上去就像“设置失败”。同理，httponly=true虽不影响存储，但JS读不到，容易误判为丢失。
- 本地开发务必设secure=false；上线前再切回true
- 用curl -I或浏览器Network面板查看原始Set-Cookie响应头，确认字段是否真实发出
- 不要仅靠document.cookie判断，而要看Application → Storage中的实际记录
