HTTP/2 本身不直接控制缓存，但通过多路复用、头部压缩等机制降低请求开销，使缓存策略更高效；需在 HTTPS 下启用，并协同配置精准缓存头、sendfile、tcp_nopush 和 open_file_cache。
HTTP/2 本身不直接控制缓存，但它通过多路复用、头部压缩、服务端推送（已弃用）等机制显著降低请求开销，让浏览器能更高效地利用已配置的缓存策略。真正起提速作用的是缓存策略本身，而 HTTP/2 让这些策略“跑得更顺”。关键在于两者协同配置，而不是单独启用某一项。
确保 HTTPS 前提与 HTTP/2 正确启用
HTTP/2 在主流浏览器中仅支持 HTTPS 环境。Nginx 必须使用 TLS 1.2+ 并开启 HTTP/2：
- server 块中 listen 指令需带 http2 参数：listen 443 ssl http2;
- 确认 SSL 证书有效，且私钥、证书链配置无误
- 禁用不安全的 TLS 协议和弱加密套件（如 TLSv1.0、RC4）
按资源类型设置精准缓存头（HTTP/2 下更关键）
HTTP/2 允许并发请求，但错误的缓存策略会导致大量无效请求或资源滞留。应严格区分资源稳定性：
-
长期不变资源（JS/CSS/字体/图片）：用 immutable + 长 max-age，避免协商缓存开销
例：add_header Cache-Control "public, max-age=31536000, immutable"; -
HTML 页面：禁用强缓存，依赖 ETag 或 Last-Modified 实现轻量协商
例：location = /index.html { add_header Cache-Control "no-cache"; } - 带哈希的静态文件（推荐）：如 main.a1b2c3.js，可放心设为 1 年缓存，更新即换名，无需担心失效问题
启用 sendfile 和 tcp_nopush，释放 HTTP/2 的传输潜力
HTTP/2 减少了连接数，但单个连接上传输效率仍依赖底层优化：
- sendfile on;：绕过用户态拷贝，由内核直接发送文件，降低 CPU 开销
- tcp_nopush on;：配合 sendfile，将响应头与首个数据块合并发送，减少 TCP 包数量
- 可选：read_ahead 1m;：对大文件预读，提升顺序读取效率
搭配 open_file_cache 提升高并发下的文件元数据性能
当大量缓存资源被反复访问时，频繁 stat() 系统调用会成为瓶颈：
- open_file_cache max=1000 inactive=30s;：缓存文件描述符及元数据
- open_file_cache_valid 60s;：每分钟检查一次缓存有效性
- open_file_cache_min_uses 2;：至少被访问 2 次才加入缓存，避免冷资源污染
不复杂但容易忽略：HTTP/2 是加速的“高速公路”，缓存策略是“交通规则”，而 sendfile 和 open_file_cache 是“车辆引擎优化”。三者缺一不可，且必须在 HTTPS 下统一生效。
