HTTPS站点启用强缓存的核心是按资源稳定性分级设置并配合immutable与构建哈希，而非统一设1年；带哈希的静态资源设expires 1y+immutable，无哈希通用资源设1d/7d，HTML禁用强缓存，同时需优化TLS会话复用、HTTP/2和keepalive以放大缓存收益。
HTTPS 站点启用强缓存的核心，不是单纯加长 expires 时间，而是让浏览器在 TLS 连接建立后，尽可能复用已缓存的静态资源，减少后续请求——尤其避免因重复加载 JS/CSS/图片引发的额外 TCP+TLS 握手。关键在于按资源稳定性分级设置，配合 immutable 和构建哈希，而非统一设 1 年。
区分资源类型，设定差异化过期时间
同一 HTTPS 域下，不同静态资产变更频率差异极大。硬性统一缓存会导致 HTML 更新不生效，或图片更新后用户看不到新内容。
-
带内容哈希的 JS/CSS/字体/图片（如 main.8a3f2b.js）：设
expires 1y，并加Cache-Control: public, immutable。immutable 告诉浏览器“此资源整个生命周期内不会变”，跳过 ETag/Last-Modified 协商请求，真正省掉一次 HTTP 往返。 -
无哈希通用资源（favicon.ico、robots.txt、manifest.json）：设
expires 1d或7d，避免长期缓存导致小文件更新不可见。 -
HTML 文件（入口页）：必须禁用强缓存，用
expires epoch或expires -1s，搭配Cache-Control: no-cache, must-revalidate，确保每次访问都拉取最新版本。
HTTPS 下需同步优化连接层，放大缓存收益
即使缓存命中，若 TLS 连接频繁重建，仍会拖慢首屏和交互响应。强缓存要和连接复用协同生效：
- 启用 SSL 会话复用：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;，让客户端复用会话票据，跳过完整握手。 - 强制 HTTP/2：
listen 443 ssl http2;，支持多路复用，在单个加密连接上并发加载多个缓存资源，避免队头阻塞。 - 延长 keepalive：
keepalive_timeout 30s;，配合前端资源引用集中（如打包后 2–3 个 JS/CSS），提升连接复用率。
配置位置与生效验证要点
expires 必须写在实际返回静态资源的 location 块中，且优先级高于 server 块；HTTPS 配置本身不影响 expires 指令逻辑，但需确保证书有效、HTTP/2 启用，否则部分缓存策略（如 immutable）在旧协议下可能被忽略。
- 推荐写法示例（放在 server 块内）：
location ~* \.(js|css|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control "public, immutable"; }location = /favicon.ico { expires 1d; add_header Cache-Control "public"; }location ~* \.html$ { expires epoch; add_header Cache-Control "no-cache, must-revalidate"; }- 验证是否生效：用
curl -I https://yoursite.com/app.a1b2c3.js查看响应头中是否有Cache-Control和Expires，时间值是否匹配预期。
构建流程必须与缓存策略对齐
expires 再精准，若前端构建没生成哈希文件名，或 HTML 中仍引用 app.js 这类无哈希路径，用户就会永远卡在旧版本。
- Webpack/Vite/Rollup 必须启用
[contenthash]，输出如main.f3e8d2a2.css； - HTML 中的 script/link 标签路径由构建工具自动注入，禁止手动写死无哈希路径；
- 上线后清空 CDN 缓存（如有），确保带新哈希的资源能被正确分发。
