Expires仅作为Cache-Control的兼容补充，需用GMT绝对时间且配合版本化资源；未哈希资源有效期宜短，哈希资源可设1年；必须与max-age共存，避免时钟偏差与部署不一致风险。
Expires 指令可用于为静态资源设置强缓存，但需注意它依赖客户端本地时间，存在时钟偏差风险，因此仅建议作为 Cache-Control 的兼容补充，不单独使用。合理设置的关键是匹配资源更新频率与版本控制机制。
Expires 设置的基本规则
Expires 值必须是 GMT 格式的绝对时间，例如：
Expires: Wed, 21 Oct 2027 07:28:00 GMT
该时间从服务器响应发出时刻起算，浏览器对比自身系统时间判断是否过期。若用户手动修改了系统时间，可能导致缓存提前失效或长期滞留——这是它不如 max-age 可靠的根本原因。
静态资源的典型有效期参考
对不带版本号的静态资源（如 logo.png、common.css），不建议设过长 Expires；对已做内容哈希或版本路径的资源（如 app.a1b2c3.js、images/bg_v2.jpg），可安全设为 1 年或更久：
- CSS / JS 文件（含 hash）：Expires 设为 1 年后（如 2027-10-21）
- 图片 / 字体文件（稳定不变）：Expires 设为 6 个月至 1 年
- Favicon.ico 或未版本化资源：Expires 不超过 7 天，避免更新不可达
与 Cache-Control 配合使用才稳妥
单独靠 Expires 不足以保障强缓存行为。现代浏览器优先采用 Cache-Control，且其 max-age 是基于请求时间的相对值，不受系统时间干扰。正确做法是两者共存：
- 服务端同时返回：
Cache-Control: public, max-age=31536000
Expires: Wed, 21 Oct 2027 07:28:00 GMT - Nginx 示例中应写为：
expires 1y;
add_header Cache-Control "public, max-age=31536000, immutable"; - “immutable” 指令可进一步提示浏览器：该资源内容永不变，即使用户刷新也不必重验（适用于带 hash 的文件）
必须规避的常见错误
忽略资源部署方式会导致 Expires 完全失效：
- 给未加 hash 的 main.js 设置 1 年 Expires → 更新后用户仍用旧缓存，白屏或报错
- Expires 时间设在“过去” → 浏览器立刻弃用缓存，每次请求都回源
- 不同环境（开发/测试/生产）用了同一份 Expires 配置 → 测试阶段无法及时验证新资源
- CDN 节点未同步 Expires 值 → 边缘节点缓存策略与源站不一致，引发资源不一致问题
