Max-Age 优先级高于 Expires，覆盖其设置；Expires 依赖客户端时间且需 GMT 格式，省略则为会话 Cookie；Max-Age 以秒为单位、不依赖本地时间，值为 0 或负数时立即删除。
Cookie 的生命周期由 Expires 和 Max-Age 两个属性共同控制，但二者作用机制不同，且存在优先级关系：当两者同时存在时，Max-Age 优先级更高，会覆盖 Expires。
Expires：基于绝对时间的过期控制
Expires 指定一个具体的 GMT 时间点（如 Expires=Wed, 21 Oct 2025 07:28:00 GMT），浏览器据此判断 Cookie 是否已过期。它的特点是：
- 依赖客户端本地系统时间，若用户手动修改了设备时间，可能导致 Cookie 提前失效或异常持久；
- 必须使用规范的 GMT 格式，常见错误是格式不合法（如时区写错、日期无效），导致浏览器忽略该字段；
- 在 HTTP 响应头中设置时，需确保时间已转为 GMT（不是本地时间或 UTC+8）；
- 如果省略
Expires且未设置Max-Age，该 Cookie 为“会话 Cookie”，关闭浏览器后即被删除。
Max-Age：基于相对秒数的过期控制
Max-Age 是一个非负整数，单位为秒（如 Max-Age=3600 表示 1 小时后过期）。它比 Expires 更可靠，因为：
- 不依赖客户端时间，由浏览器根据设置时刻自动计算到期时间；
- 值为
0或负数时，表示立即删除该 Cookie（常用于登出逻辑）； - 现代浏览器普遍支持，且 RFC 6265 明确推荐优先使用
Max-Age； - 与
Expires共存时，Max-Age生效，Expires被忽略。
实际设置方式与注意事项
服务端可通过响应头 Set-Cookie 设置这两个属性，例如：
或同时设置（但 Max-Age 起效）：
注意要点：
- JavaScript 中通过
document.cookie设置时，仅支持expires（小写），不支持max-age；需将相对秒数换算为Date对象再赋值； - 若需兼容老旧客户端（如某些 IE 版本），可同时设置两者，以
Max-Age为主、Expires为备； - 安全敏感 Cookie（如认证凭证）应配合
Secure、HttpOnly、SameSite等属性一并设置。
常见误区与调试建议
开发中容易踩的坑包括：
- 误把
Max-Age=0当作“永不过期”——实际是立即删除； - 在
Set-Cookie中拼写错误，如写成Maxage或max-age（必须是Max-Age，大小写敏感）； - 未验证浏览器行为：可用 DevTools 的 Application → Cookies 面板查看实际生效的过期时间；
- 服务端框架（如 Express、Django）通常封装了 Cookie 设置逻辑，需查阅文档确认其对
maxAge参数的处理是否映射为Max-Age或自动生成Expires。
