HTTP/2多路复用工作在应用层，依赖服务器启用HTTP/2及TLS配置，HTML标签本身不控制该机制；浏览器请求是否复用取决于协议协商结果，而非HTML结构或属性。
HTML 本身和 HTTP/2 多路复用没有直接关系——<html> 标签不会触发、控制或感知多路复用。真正起作用的是浏览器发起资源请求时底层使用的 HTTP 协议版本，以及服务器是否支持并启用 HTTP/2。
HTTP/2 多路复用发生在哪一层？
它完全工作在传输层之上的应用层协议栈中，具体是 TCP 连接建立后、HTTP 消息交换阶段的机制。浏览器解析 HTML 遇到 <script>、<link rel="stylesheet">、<img> 等标签时，会按需发起 HTTP 请求；这些请求是否走多路复用，取决于：
- 当前域名是否已协商升级到 HTTP/2（通过 TLS 握手中的 ALPN 或明文 h2c）
- 服务器是否配置了 HTTP/2 支持（如 Nginx 的
http2 on，Apache 的Protocols h2 http/1.1） - 客户端（浏览器）实际发起请求时复用的是同一个连接，而非为每个资源新建 TCP 连接
为什么改写 HTML 无法“开启”多路复用？
常见误解是：把多个 <script> 合并、加 async 或 defer、用 preload 就等于利用了多路复用。其实这些只是影响资源加载时机和执行顺序，不改变协议行为：
-
<link rel="preload" as="script">只是提前触发请求，仍依赖底层 HTTP 版本 - 即使 HTML 中写了 20 个
<img>，在 HTTP/1.1 下浏览器仍受限于 6 个并发连接，且存在队头阻塞 - 在 HTTP/2 下，这 20 个请求可全部复用一个连接，并行发送帧，流 ID 不同、互不阻塞
怎么确认你的 HTML 页面正受益于多路复用？
不能只看 HTML 源码，得查网络行为：
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome DevTools → Network 面板 → 刷新页面 → 点击任意请求 → 查看 Headers 标签页 → 找
:scheme或Protocol字段：值为h2表示走 HTTP/2 - 在 Network 面板顶部勾选 “Waterfall”，观察同域名下多个请求的“Start Time”是否高度重叠（而非阶梯式错开），这是多路复用的典型表现
- 对比禁用 HTTP/2 后（如 Nginx 关掉
http2并重启），同样 HTML 页面的请求数、连接数、TTFB 和完成时间变化
真正容易被忽略的点是：多路复用的效果高度依赖服务器配置和 TLS 设置。哪怕 HTML 写得再优化，如果服务端没启用 HTTP/2 或用了不兼容的 TLS 版本（如低于 1.2），浏览器就只能降级到 HTTP/1.1，所有流帧、优先级、头部压缩都失效。
