http/2多路复用自动启用，需客户端和服务端均支持、tls层alpn协商成功（或h2c升级完成）；验证需检查协议版本、单连接多流行为及连接复用效果。
加载速度提升不靠“协议升级”本身，而靠协议升级后释放的并发潜力被真正用起来。HTTP/2 的多路复用只是把多个请求塞进一个连接里并发发出去，但若服务端、客户端或网络链路没配好，这个并发就卡在半路，页面照样卡顿。
服务端必须支持 TLS + ALPN 协商
HTTP/2 在生产环境强制要求 HTTPS，且需 TLS ≥ 1.2（推荐 1.3）和 ALPN 协议协商能力。Nginx 低于 1.9.5、Apache 未启用 mod_http2、或证书无效（如自签名、过期、域名不匹配），浏览器会静默降级回 HTTP/1.1，多路复用根本不会触发。
- 检查 Nginx 配置中是否含 listen 443 ssl http2;，而非仅 ssl
- 确认 ssl_protocols 明确包含 TLSv1.2 和 TLSv1.3
- 用 openssl s_client -alpn h2 -connect example.com:443 验证 ALPN 是否返回 h2
客户端要主动发起并发请求，不能只靠协议“自动并行”
HTTP/2 不改变后端执行逻辑。前端仍需显式并发调用接口（如 Promise.all、useQuery + parallel queries），否则即使走的是 HTTP/2 连接，10 个请求也可能被后端串行处理——尤其当它们共用数据库连接池或落在同一个同步 worker 进程上。
- 避免在单个接口内嵌套串行调用（如先查用户再查订单再查权限）
- 移动端使用 OkHttp 或 URLSession 时，确保启用连接复用（默认开启）和流优先级设置
- 对首屏关键请求设高权重（weight=256），防止被埋点、日志等低优请求拖慢
调优服务端多路复用参数，适配弱网与高延迟场景
默认配置在弱网下容易失效：流数上限太低导致新请求排队；初始窗口太小引发频繁 WINDOW_UPDATE；空闲超时太长积压无效连接。
- http2_max_concurrent_streams 建议设为 256 或 512（默认 128）
- http2_initial_window_size 可调至 131072（默认 65535），缓解小包传输抖动
- http2_idle_timeout 建议 45s～60s，配合客户端健康探测更可靠
后端应用层无需改代码，但架构得跟上
HTTP/2 是传输层协议，Spring Boot、FastAPI、Express 等框架收到的仍是标准 HTTP 请求对象。真正瓶颈常在后端：同步 DB 查询、阻塞式第三方调用、线程池过小、Gunicorn/Uvicorn worker 数不足。这些不优化，协议再先进也白搭。
- 将耗时 I/O 操作改为异步（async/await、CompletableFuture、Mono）
- 数据库连接池大小需匹配并发流数，避免请求在池外等待
- 反向代理（如 Nginx）与后端之间建议也启用 HTTP/2 或至少 keepalive 长连接
