https下强缓存核心是分级策略：带哈希静态资源配expires 1y+immutable实现零往返；无哈希通用资源设1d/7d；html禁用强缓存；需http/2、ssl会话复用与keepalive协同优化。
在 HTTPS 环境下配置强缓存，核心不是简单设个 expires 1y，而是让浏览器真正“信得过”资源不会变——从而跳过所有验证请求，实现零往返加载。关键在于资源稳定性分级 + 构建哈希 + immutable 响应头 + 连接层协同优化。
按资源类型分级设置缓存策略
统一设一年会出问题：HTML 更新了用户看不到，带哈希的 JS 却被反复校验。
-
带内容哈希的静态资源（如
app.a2b3c4.js、style.f1e0d9.css、icon.786543.woff2）：
用expires 1y+Cache-Control "public, immutable"。immutable 告诉浏览器“这个 URL 永远对应同一份内容”，彻底跳过 ETag 或 Last-Modified 验证。 -
无哈希但更新频率低的资源（如
favicon.ico、robots.txt、manifest.json）：
设expires 1d或7d，加Cache-Control "public"，避免长期缓存导致小文件更新不可见。 -
HTML 入口页（如
/index.html）：
必须禁用强缓存：add_header Cache-Control "no-cache, must-revalidate";，配合expires epoch或expires -1s，确保每次访问都拉取最新版本。
启用 immutable 并确保协议支持
immutable 只在 HTTPS + HTTP/2 下稳定生效。HTTP/1.1 浏览器可能忽略它，而未启用 HTTP/2 的 Nginx 配置会导致该头形同虚设。
- 监听配置中必须包含
http2：listen 443 ssl http2; - 证书需有效且支持 ALPN 协议协商（现代 Let’s Encrypt 默认支持）
- 不要对 HTML 或动态接口加 immutable——它只适用于构建时生成、URL 不变的资源
同步优化连接层，放大缓存收益
缓存再快，如果每次都要重建 TLS 连接，首屏加载仍卡顿。强缓存必须和连接复用配合才能发挥最大价值。
- 启用 SSL 会话复用：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h; - 延长 keepalive：
keepalive_timeout 30s;，让浏览器复用单个连接加载多个缓存资源 - 开启 sendfile 和 tcp_nopush：
sendfile on; tcp_nopush on;，减少内核拷贝与小包数量
验证是否生效
别只看 Cache-Control 头是否存在，重点检查三件事：
- 浏览器开发者工具 Network 标签中，目标资源状态码是否为
200 (from memory cache)或200 (from disk cache)（非304） - 响应头中是否同时存在
Cache-Control: public, immutable和Expires（时间戳应为 1 年后） - 第二次访问时，该资源请求是否完全不发出（即无网络请求记录）
