max-age优先于expires且更可靠；expires必须为rfc 7231规定的gmt格式（如wed, 21 oct 2025 07:28:00 gmt），否则被静默忽略退化为会话cookie；document.cookie仅支持expires，需用toutcstring()生成；服务端set-cookie推荐用max-age。
max-age 优先于 expires，且更可靠；前端用 document.cookie 只能设 expires，必须转成 GMT 字符串；服务端设 Set-Cookie 时两者都支持，但应优先用 Max-Age。
为什么 expires 总是不生效？
浏览器只认 RFC 7231 规定的 GMT 格式，比如 Wed, 21 Oct 2025 07:28:00 GMT。写成本地时间、ISO 格式（如 "2025-12-31T23:59:59"）、或拼错月份缩写（Jun 写成 June），都会被静默忽略，退化为会话 Cookie。
- 别手写字符串——容易漏空格、大小写错、时区错
- 用
new Date().toUTCString()生成，例如：document.cookie = "theme=dark; expires=" + new Date(Date.now() + 7 * 24 * 60 * 60 * 1000).toUTCString(); -
toGMTString()已废弃，不要用
max-age 和 expires 同时出现时谁起作用？
只要 Max-Age 存在（注意大小写），Expires 就被完全忽略，哪怕 Expires 写的是 2030 年，Max-Age=60 也只活 60 秒。
- HTTP 响应头中必须写成
Max-Age=3600（首字母大写、中间横线、单位秒） - 写成
max-age、Maxage或max_age都无效 - 前端 JS 无法通过
document.cookie设置max-age，只能靠服务端或换算成expires
设置后 Cookie 还是“秒没”，可能卡在哪？
过期时间本身没错，但 Cookie 消失得早，大概率不是时间问题，而是路径、域名或安全策略导致读不到或写不进。
-
path不匹配：比如设了path=/admin，但在/下执行document.cookie查不到——这不是过期，是隔离 -
domain设错：从app.example.com写domain=example.org会失败，且无任何提示 - 缺
Secure或SameSite：Chrome 等现代浏览器可能直接拒收，尤其在 HTTPS 页面下 -
HttpOnlyCookie：JS 根本读不到，document.cookie查不到不等于它不存在或已过期
调试时别只信 DevTools 的 “Expires” 列
Application > Cookies 面板里显示的 “Expires” 是浏览器根据 Max-Age 或 Expires 推算出的本地时间，但它可能不准——系统时间被调过、Cookie 被脚本覆盖、或被浏览器策略拦截后，面板显示和实际行为就对不上。
- 真正判断是否还存在，应该用
document.cookie实际读取（非HttpOnly场景） - 服务端可通过日志或抓包确认响应头中
Set-Cookie字段是否正确输出了Max-Age或Expires - IE 6–8 不支持
Max-Age，若真要兼容，才需 fallback 到expires，否则没必要
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
