Expires 不能单独实现可靠强缓存，必须与 Cache-Control 配合使用，其本质缺陷是依赖客户端系统时间，易因时间偏差导致缓存提前失效或长期滞留；HTTP/1.1 规定 Cache-Control 优先级更高，Expires 仅作 HTTP/1.0 兼容补充。
Expires 指令本身不能单独实现可靠强缓存，它必须与 Cache-Control 配合使用，且仅作为 HTTP/1.0 兼容补充。真正起决定作用的是 max-age，而 Expires 只是提供一个 GMT 绝对时间戳——一旦客户端时间不准，缓存就可能提前失效或长期滞留。
为什么不能只靠 expires
Expires 的本质缺陷是依赖客户端系统时间：
- 服务器设了
Expires: Wed, 21 Oct 2027 07:28:00 GMT，但用户电脑快了2小时 → 浏览器立刻认为已过期，每次请求都回源 - 用户手动把系统时间调到2030年 → 所有带 Expires 的资源全被跳过，页面彻底白屏或错乱
- HTTP/1.1 规范明确要求：当 Cache-Control 和 Expires 同时存在，Cache-Control 优先级更高，Expires 被忽略
expires 正确用法：必须搭配 Cache-Control
在 Nginx 中，应始终用 add_header 显式设置 Cache-Control，并让 expires 指令生成对应 GMT 时间作为兜底：
小红书长文-谷歌浏览器
下载
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
location ~* \.(js|css|png|jpg|gif|woff2|svg)$ { expires 1y; add_header Cache-Control "public, max-age=31536000, immutable"; }location = /favicon.ico { expires 1d; add_header Cache-Control "public, max-age=86400"; }location ~* \.html$ { expires -1; add_header Cache-Control "no-cache, no-store, must-revalidate"; }
注意：expires 1y 会自动计算出未来一年的 GMT 时间填入 Expires 头；max-age=31536000 则以请求时刻为起点算相对有效期，二者逻辑一致但机制互补。
不同资源类型该设多久
有效期不是越长越好，关键看是否做了内容哈希（如 app.a1b2c3.js）：
- 带哈希或版本路径的 JS/CSS/图片/字体 → 可设
expires 1y+immutable，安全放心 - 未哈希的通用资源（
favicon.ico、robots.txt、manifest.json）→ 建议expires 1d或更短，避免更新不可达 - HTML 文件 → 不建议缓存，或最多
expires 10m，确保用户能及时拿到新入口
常见踩坑点
这些错误会让 expires 完全失效甚至起反作用：
- 开发环境和生产环境共用同一份 expires 配置 → 测试时改了 JS 却刷不出来，因为浏览器还在用旧缓存
- CDN 节点没透传或覆盖了源站的 Expires 和 Cache-Control → 边缘节点缓存策略混乱，用户看到混合版本
- 把
expires -1写成expires 0→ Nginx 会解析为“立即过期”，等效于no-cache，但语义易混淆 - 静态资源路径没做哈希，却配了
expires 1y→ 用户更新后仍加载旧文件，只能靠清缓存或强制刷新
