Expires仅支持绝对时间，必须为RFC 1123规范的GMT格式（如Expires: Sat, 21 Oct 2027 08:30:00 GMT），不支持相对时间；其可靠性受客户端时间同步影响，现代缓存应优先使用Cache-Control: max-age。

Expires 本身只支持绝对时间，不支持相对时间。所谓“Expires 中的相对时间选型”是一种常见误解——真正处理相对时间的是 Cache-Control: max-age，而 Expires 是 HTTP/1.0 定义的、仅基于 GMT 绝对时间点的过期机制。

Expires 必须用绝对时间，且格式严格

它的值必须是符合 RFC 1123 规范的 GMT 时间字符串，例如：

• ✅ 正确：Expires: Sat, 21 Oct 2027 08:30:00 GMT
• ❌ 错误：Expires: 2027-10-21T08:30:00+00:00（ISO 格式）
• ❌ 错误：Expires: 3600（秒数，这是 max-age 的写法）
• ❌ 错误：Expires: next week（自然语言，服务器无法解析）

任何非 GMT 格式或本地时间都会被浏览器忽略，导致缓存行为不可控。

为什么绝对时间在 Expires 中不可靠？

核心问题在于客户端系统时间可被用户随意修改，而 Expires 完全依赖该时间做判断：

• 用户把电脑时间调快 1 年 → 所有带 Expires 的资源立刻失效，全部回源请求
• 用户把电脑时间调慢 1 年 → 过期资源仍被强缓存，用户看不到更新内容
• 服务端与客户端时钟不同步（哪怕差几分钟）→ 缓存提前或延迟过期

这种不确定性正是 Cache-Control 被设计出来的根本原因。

什么时候还值得用 Expires？

它不是完全淘汰，而是退居为兼容性补充角色：

• 需要支持极老代理或 HTTP/1.0 客户端（如某些嵌入式设备）
• 配合 Cache-Control 共同下发，作为双保险（现代浏览器优先认 max-age，旧环境 fallback 到 Expires）
• 静态资源部署已做内容哈希（如 app.a1b2c3.js），且服务端能稳定生成未来 GMT 时间（如 Nginx expires max）

单独使用 Expires 已不被推荐，尤其对动态接口、登录态、HTML 页面等易变内容。

选型建议：按资源类型决定策略

关键不是“Expires 用相对还是绝对”，而是“什么场景该用 Expires，什么该交给 Cache-Control”：

• 带哈希名的 JS/CSS/图片：用 Cache-Control: public, max-age=31536000, immutable，可加 Expires 作兼容
• 未哈希的 favicon.ico 或通用 CSS：设短 max-age（如 86400），不建议设 Expires；若必须设，不超过 7 天
• HTML 页面或 API 响应：禁用强缓存，用 Cache-Control: no-cache 或 max-age=0，完全不用 Expires
• Cookie 的过期控制：优先用 Max-Age=3600（相对秒数），仅在需兼容 IE 等旧浏览器时补 Expires GMT 时间

现代工程实践中，Expires 只是配置脚本里一行顺带的兼容字段，不是缓存逻辑的设计起点。