为何已有Expires仍为Cookie引入Max-Age属性？

先明确：Expires和Max-Age核心都是控制Cookie过期，但Max-Age绝非只是格式不同的冗余属性，而是为了弥补Expires的固有缺陷才被引入的。

Expires的固有问题 #

• 依赖客户端系统时间，极易出错：Expires指定的是绝对过期时间点，这要求客户端与服务器时间严格同步。如果用户手动修改系统时间、时区设置错误，Cookie的过期逻辑会彻底混乱——要么提前失效，要么永久有效，既影响体验还可能带来安全风险（比如永久有效的认证Cookie）。
• 开发维护成本高：服务器生成Expires值时，需要计算当前时间加有效期，再转换成严格的HTTP日期格式（如Wed, 21 Oct 2015 07:28:00 GMT），还要处理时区转换，稍不注意就会格式错误，导致过期逻辑失效。
• 临时Cookie/删除Cookie的表达不直观：要让Cookie立即失效，Expires需设置过去的时间点，但不同旧浏览器对“过去时间”的处理存在差异；会话Cookie（关闭浏览器失效）虽可不设Expires，但语义上远不如Max-Age明确。

Max-Age的解决优势 #

• 完全不依赖客户端时间：Max-Age是从客户端收到Cookie的时刻起计算的相对秒数，不管客户端时间如何修改，过期逻辑始终准确——比如设Max-Age=3600，就一定是1小时后过期，彻底避免了时间同步问题。
• 语义清晰，开发更高效：要设置24小时有效期，直接写Max-Age=86400即可，无需计算绝对时间、纠结HTTP日期格式，大幅降低开发和维护的出错概率。
• 灵活控制生命周期：要立即删除Cookie，直接设Max-Age=-1；要设会话Cookie，Max-Age=0（语义比不设Expires更明确），逻辑一目了然，无歧义。

二者的适用场景 #

• Expires：主要用于兼容旧浏览器（如IE8及更早版本），或确实需要精确到某个绝对时间点让Cookie失效的场景（比如营销活动结束后，立即停止相关Cookie生效）。
• Max-Age：现代浏览器环境下的首选，尤其是需要相对时长控制的场景（如登录会话保持7天、临时Token有效期15分钟），既安全又省心。

内容的提问来源于stack exchange，提问作者Arad