HTTP/2多路复用由协议层自动启用，无需HTML手动开启；关键在于统一主域名避免子域名分片、用preload提前触发关键资源请求并设as属性、禁用同步脚本阻塞解析、验证Protocol为h2且同域名请求共享Connection ID。
HTTP/2 的多路复用本身不需要你在 HTML 里“开启”，它由服务器和浏览器协商自动启用；真正影响加载速度的，是你怎么写 HTML、怎么组织资源、怎么调度请求——稍不注意，就等于把高速公路修好了，却自己设了路障。
统一主域名，别再拆子域名
很多项目还沿用 HTTP/1.1 时代的做法，把图片、JS、CSS 分到 static1.example.com、cdn.example.com 等多个子域名。这在 HTTP/2 下反而拖慢加载：
- 每个子域名要单独完成 TLS 握手和 SETTINGS 协商，增加 RTT 延迟
- 浏览器无法跨域名复用 TCP 连接，多路复用流 ID 不共享，优先级调度失效
- CDN 配置或证书 SNI 差异可能导致连接被强制断开重连
解决方法很简单：所有静态资源都走同一主域名，比如 https://example.com/assets/main.js、https://example.com/images/logo.png。实测显示，单域名 + HTTP/2 通常比 4 子域名 + HTTP/1.1 快 15–30%。
用 preload 抢占复用通道的空闲时间
浏览器解析 HTML 是线性的，遇到 <script src="app.js"> 才发起请求，中间几十毫秒连接可能空转。而 preload 能在解析早期就触发请求，填满复用通道：
- 必须带 as 属性，例如
<link rel="preload" href="/styles.css" as="style">，否则浏览器无法设置正确 Accept 头和缓存策略 - 只对关键首屏资源使用（如 above-the-fold CSS、主 JS、核心图片），非关键资源（分析脚本、页脚广告）会挤占带宽
- preload 不阻塞 HTML 解析，但能提升该资源在复用流中的调度优先级
- 它不会自动执行——
<script>仍需显式引入才能运行
避免同步脚本阻塞后续请求触发
即使启用了 HTTP/2，一个没加 async 或 defer 的外部 <script> 仍会暂停 HTML 解析，导致后续 <img>、<link> 标签无法及时发出请求——复用连接空着，浏览器却“不敢发”：
- 对非首屏依赖的 JS，优先用
async（无执行顺序保证）或defer（按文档顺序执行） - 若必须同步加载（如某些初始化逻辑），考虑将强依赖打包进同一文件，减少请求数，而不是靠多路复用来掩盖阻塞
- 注意：多路复用解决的是传输层队头阻塞，不是执行层阻塞；
document.write()或未声明依赖的import依然会报错
验证是否真正在用多路复用
别光看瀑布图“看起来快”，要确认底层机制生效：
- 打开 Chrome DevTools → Network 面板，选中任意请求，看 Header 里的 Protocol 字段是否为 h2
- 筛选同域名下的多个请求（如
/app.js、/logo.png、/main.css），检查它们的 Connection ID 是否一致 - 如果 Protocol 是 h2 且 Connection ID 相同，说明多路复用已实际工作；否则可能是服务器配置未启用 HTTP/2，或资源被错误分到不同域名
