HTTP/2多路复用是核心优势而非问题，误判常源于开发调试中对加载顺序、执行时序或协议降级的误解；验证需看Protocol列为h2且同域名多请求共用Connection ID。
HTTP/2 多路复用不是“问题”，不需要“怎么办”
HTTP/2 的多路复用（multiplexing）是协议的核心优势，不是 bug，也不需要“解决”或“关闭”。你看到的所谓“问题”，通常是资源加载行为与 HTTP/1.1 时期直觉不符导致的误判，比如：CSS/JS 加载顺序看似混乱、console.time() 测出的请求时间重叠、或 DevTools 中看到大量 pending 状态但实际页面渲染没卡顿。这恰恰说明多路复用在正常工作。
哪些情况会让人误以为多路复用“出问题”
常见触发场景集中在开发调试和资源依赖关系上：
- 你在 Chrome DevTools 的
Network标签页中按Start Time排序，发现多个.js文件的Start Time几乎一致，误以为“没按顺序发起”——其实它们是同个 TCP 连接内并发帧，顺序由服务器响应帧的stream ID和优先级决定，不是发起时间决定的 - 你用
document.write()或同步script标签依赖另一个脚本就绪，但 HTTP/2 下后者可能还没执行完（因传输快但解析/执行仍串行），造成ReferenceError——这不是多路复用的问题，是脚本执行时序没控制好 - 你在 Nginx/Apache 后端启用了 HTTP/2，但前端仍用
http://加载资源，浏览器降级走 HTTP/1.1，此时看不到多路复用效果，却怀疑配置失效
真正要检查的是 Server Push 和优先级设置
HTTP/2 的实际表现差异主要来自服务端推送（Server Push）和权重（weight）配置，而非多路复用本身：
- Server Push 已被主流浏览器弃用（Chrome 96+、Firefox 90+ 完全移除），如果你在 Nginx 配置里还写了
http2_push，它不会生效，且可能干扰缓存逻辑；直接删掉相关配置更干净 - 资源优先级靠
link rel="preload"或fetchpriority="high"显式声明，而不是靠文件名或路径；不设优先级时，浏览器默认按 HTML 解析顺序分配权重，但多路复用下这个顺序不再对应网络层发送顺序 - 若用 Node.js 的
http2模块，注意stream.priority参数只影响同连接内流调度，无法跨连接控制；真实体验更取决于 CDN 是否支持SETTINGS_ENABLE_PUSH = 0及是否开启 HPACK 压缩
验证多路复用是否生效的唯一可靠方式
别看 DevTools 的瀑布图，那只是 UI 抽象。真正在意是否启用多路复用，只看两点：
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome DevTools →
Network→ 右键表头 → 勾选Protocol列，所有请求显示为h2（不是http/1.1或空） - 在同一个域名下发起 ≥2 个资源请求（如一个
main.css+ 一个logo.png），观察它们的Connection ID（在 Headers → Response Headers 中找x-http2-connection-id或类似字段，取决于后端实现）是否相同 - 用命令行验证：
curl -I --http2 https://yoursite.com/，如果返回含HTTP/2 200且无Upgrade: h2c跳转，说明 TLS 层已协商成功
多路复用的复杂点不在客户端代码，而在你是否混淆了传输层并发和应用层执行顺序；最容易被忽略的是：即使开了 HTTP/2，如果资源分散在多个子域（如 static1.example.com、static2.example.com），浏览器仍会为每个子域建独立连接，多路复用效益归零。
