全站启用http/2后静态资源缓存高效稳定的核心是https协商、连接复用、缓存策略与文件访问四者协同；需确保alpn协商成功（listen 443 ssl http2且ssl_protocols tlsv1.2+）、对哈希资源设immutable强缓存、启用open_file_cache与sendfile零拷贝，并通过protocol列和connection id验证复用效果。
全站启用 HTTP/2 后，静态资源缓存要真正高效稳定，核心不是单独调优某一项，而是让 HTTPS 协商、连接复用、缓存策略和文件访问四者协同——HTTP/2 的多路复用放大了缓存失效或元数据查询慢的负面影响，也放大了强缓存+零拷贝带来的收益。
确保 TLS 层完全支持 HTTP/2 并稳定协商
HTTP/2 在浏览器端强制走 HTTPS，且依赖 ALPN 协议扩展完成协商。若这一步失败，所有后续优化都降级为 HTTP/1.1。
- listen 指令必须明确包含 http2：如
listen 443 ssl http2;，不能只写ssl - 验证 ALPN 是否生效：运行
openssl s_client -alpn h2 -connect your.site:443 -servername your.site 2>/dev/null | grep "ALPN protocol"，输出应为h2 - 禁用旧协议：在 server 块中设置
ssl_protocols TLSv1.2 TLSv1.3;，避免因协商降级导致 HTTP/2 被跳过 - 证书需由支持 ALPN 的 CA 签发（如 Let’s Encrypt 默认满足），且私钥不加密（Nginx 不支持加载加密私钥启动 http2）
静态缓存策略适配 HTTP/2 的多流特性
HTTP/2 允许单连接并发多个 stream，因此缓存设计应减少“验证请求”、延长连接复用时间，而不是频繁新建连接去校验。
- 对带哈希指纹的资源（如
app.a1b2c3.js）启用长效不可变缓存：add_header Cache-Control "public, max-age=31536000, immutable"; - 避免对已压缩格式（JPEG、PNG、woff2、mp4）启用 gzip 或 brotli，节省 CPU，把连接资源留给更多并发 stream
- HTML 文件保持短缓存或 no-cache，防止用户看到陈旧页面；可用
add_header Cache-Control "no-cache, must-revalidate"; - 配合
expires 1y;和add_header Last-Modified "";清除默认时间头，避免触发条件请求（If-Modified-Since）打断 stream 复用
文件系统层缓存与传输优化不可缺位
HTTP/2 多路复用下，大量并发请求会同时触发文件查找和读取，若 open_file_cache 或 sendfile 配置不当，CPU 和磁盘 I/O 会成为瓶颈。
- 全局启用高效元数据缓存：
open_file_cache max=10000 inactive=60s;<br>open_file_cache_valid 30s;<br>open_file_cache_min_uses 2;<br>open_file_cache_errors on;
- 静态 location 中开启零拷贝：
sendfile on;<br>tcp_nopush on;<br>tcp_nodelay off;
（对大文件关闭 nodelay，减少小包数量） - 高频静态路径关闭访问日志：
access_log off;，防止高并发时磁盘 IOPS 成瓶颈 - 使用
alias替代root映射目录，避免路径拼接开销，缩短单个 stream 的响应路径
验证是否真正发挥 HTTP/2 缓存优势
光看配置不够，需通过真实链路确认效果。
- 浏览器开发者工具 Network 标签页，检查每条请求的 Protocol 列是否均为
h2，Connection ID 是否高度复用（同一 ID 出现多次） - 用
curl -I --http2 https://yoursite.com/static/app.js查看响应头是否含cache-control且值符合预期 - 监控 Nginx 状态：关注
Active connections数量是否平稳、Reading/Writing/Waiting分布是否合理，Waiting 过高可能说明缓存未命中导致阻塞 - 对比启用前后：相同压测条件下，QPS 提升是否伴随 5xx 错误率下降、平均响应时间方差收窄（稳定性提升）
