expires必须用rfc 7231规定的gmt（即utc）格式字符串，如“wed, 21 oct 2025 07:28:00 gmt”，本地时间或iso格式会被忽略而退化为会话cookie；max-age优先于expires，以秒为单位更可靠。
设置 expires 时必须用 GMT 时间格式
浏览器只认 RFC 7231 规定的 GMT（即 UTC）时间字符串，写成本地时间或 ISO 格式（如 "2025-12-31T23:59:59"）会被直接忽略，Cookie 变成会话级（关闭浏览器即失效）。
实操建议：
- 用
new Date().toUTCString()生成合法值，例如：document.cookie = "theme=dark; expires=" + new Date(Date.now() + 7 * 24 * 60 * 60 * 1000).toUTCString(); - 别手写时间字符串——容易漏空格、拼错月份缩写（
Jun不是June），也别依赖toGMTString()（已废弃） - 如果后端 Set-Cookie，同样要确保服务端输出的
Expires值符合Wed, 21 Oct 2025 07:28:00 GMT格式
max-age 比 expires 更可靠
max-age 是以秒为单位的相对时长，由浏览器自行计算到期时刻，不依赖客户端时间设置。当 max-age 和 expires 同时存在时，现代浏览器优先采用 max-age。
常见错误现象：用户电脑时间被手动调慢几小时，导致 expires 提前触发删除，而 max-age 不受影响。
实操建议：
- 前端设置优先用
max-age：document.cookie = "token=abc123; max-age=3600; path=/"; -
max-age=0表示立即删除（等价于设一个过去的时间），但注意：它不能删除HttpOnlyCookie - IE 6–8 不支持
max-age，若需兼容老 IE，才需 fallback 到expires
路径（path）和域名（domain）影响 Cookie 的生命周期感知范围
即使设置了 max-age 或 expires，如果后续读取时 path 不匹配，JavaScript 就看不到这个 Cookie，容易误判“过期了”或“没生效”。
使用场景举例：登录态 Cookie 设在 path=/admin，但在首页 / 下执行 document.cookie 查不到它——这不是过期，是路径隔离。
实操建议：
- 设置时显式声明
path（通常为/），避免默认继承当前路径 -
domain必须是当前域的父域（如从app.example.com可设domain=example.com），设错会导致写入失败且无提示 - Secure 和 SameSite 属性虽不直接影响过期，但若缺失，某些浏览器（尤其 Chrome）可能拒绝存储，间接让“过期设置”白做
调试时别只看 Application > Cookies 面板里的“Expires”列
DevTools 显示的“Expires”是浏览器根据 max-age 或 expires 计算出的本地时间，但这个值可能和实际行为不一致——比如系统时间不准、Cookie 被策略拦截、或已被脚本覆盖。
更可靠的验证方式：
- 刷新页面后执行
document.cookie，确认键名是否还在返回值中 - 用
fetch发起一次请求，抓包看 Request Headers 中是否携带该 Cookie（判断是否仍有效发送） - 注意：Chrome 的 Application 面板里，灰色显示的 Cookie 表示已过期或被标记为
HttpOnly（JS 无法访问）
关键点其实就两个：时间值必须合法且与时区无关，作用域参数必须和读取时完全一致。其余都是围绕这两点产生的副作用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
