HTTP/2多路复用是协议强制要求的核心机制，不可关闭或绕过；其端到端生效依赖客户端、TLS（ALPN协商h2）、代理链路及源站的完整HTTP/2支持，任一环节降级即失效。
HTTP/2 多路复用不是可选项，而是协议强制要求的核心机制；没有它，就不是合法的 HTTP/2 实现。
HTTP/2 的多路复用是协议层硬性规定
HTTP/2 标准（RFC 7540）明确要求所有实现必须支持帧（frame）和流（stream）抽象，并在单个 TCP 连接上并发处理多个请求/响应。这意味着：SETTINGS_ENABLE_PUSH 可以被禁用，但多路复用本身无法关闭或绕过。
- 浏览器发起 HTTP/2 请求时，
SETTINGS帧中必须包含SETTINGS_MAX_CONCURRENT_STREAMS，服务端也必须遵守该值进行流调度 - 若服务端强行串行处理流（例如把所有请求塞进一个队列顺序执行），虽然连接能建立，但会严重违背 HTTP/2 设计目标，导致实际性能不如 HTTP/1.1
- Nginx、Apache、Caddy 等主流服务器启用 HTTP/2 后，默认即启用多路复用，无需额外配置开关
HTML 资源加载不直接控制多路复用，但影响其效果
HTML 本身只是文本标记，不参与 HTTP/2 流管理。但它组织资源的方式，会显著影响多路复用能否发挥优势：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 使用
<link rel="preload">提前声明关键资源，能让浏览器更早发起多个并行流，避免因 HTML 解析延迟导致的流空闲 - 避免在
<script>中同步阻塞加载（如未加async或defer的外部脚本），否则会卡住后续资源的流创建时机 - CDN 或反向代理若不支持 HTTP/2（例如只透传到后端 HTTP/1.1），则客户端与边缘节点之间虽有多路复用，但边缘与 origin 之间仍是串行请求——此时 HTML 中的资源数量越多，后端瓶颈越明显
常见误判：看到“多个请求排队”就以为多路复用失效
Chrome DevTools 的 Network 面板中，即使启用了 HTTP/2，仍可能看到请求显示为“queued”或“stalled”，但这通常不是多路复用的问题：
立即学习“前端免费学习笔记（深入）”；
-
queued状态常源于浏览器对同一域名的并发流数限制（由SETTINGS_MAX_CONCURRENT_STREAMS控制，默认通常是 100），而非连接层失败 - 真正的问题信号是：多个请求长期处于
waiting (TTFB)且时间远超 100ms，同时Protocol列显示h2—— 此时应排查后端处理延迟，而非怀疑多路复用没生效 - 用
curl -I --http2 https://example.com查看响应头是否含HTTP/2 200，再配合 Wireshark 抓包过滤http2流，才能确认多路复用是否真实工作
多路复用的底层行为完全由 HTTP/2 协议栈控制，前端无法用 HTML 或 JS 手动开启/关闭；真正容易被忽略的是：它依赖端到端支持——从客户端、TLS 层（ALPN 必须协商 h2）、代理链路，到 origin server 的完整 HTTP/2 实现，任一环节降级都会让多路复用形同虚设。
