HTTP/2多路复用是传输层能力，不依赖HTML结构，但HTML资源引用方式决定其效能；应统一域名、善用preload、避免Server Push。
HTTP/2 多路复用不依赖 HTML 结构，但 HTML 加载模式会暴露其效果
HTTP/2 的多路复用是传输层能力，浏览器在建立单个 TCP 连接后，可并行收发多个 HTTP 请求/响应帧，无需等待前一个完成。它对 HTML 本身无感知——<link>、<script>、<img> 标签怎么写，协议层照样复用流。但 HTML 的资源引用方式，决定了你能否让多路复用“有活干”：
- 把 20 个
<script src="a.js">拆成 20 个独立请求？HTTP/2 能扛住，但仍是 20 次逻辑请求，浪费流 ID 和头部开销 - 用
<link rel="preload">提前触发关键资源拉取？能更早占满复用通道，减少空闲窗口 - HTML 中混用 HTTP/1.1 域名（如
cdn1.example.com）和 HTTP/2 域名？会导致连接分裂，复用失效
避免在 HTML 中主动“拆分域名”来“优化加载”
这是 HTTP/1.1 时代的惯性操作：为绕过浏览器 6 连接限制，把资源分散到 static1.example.com、static2.example.com……但在 HTTP/2 下，这种做法反而破坏多路复用：
- 每个子域名需单独 TLS 握手 +
SETTINGS帧协商，增加延迟 - 资源被隔离在不同 TCP 连接上，无法共享流、无法优先级调度
- 浏览器可能因 SNI 或证书差异，拒绝复用已建立的连接
- 真实场景中，单域名 + HTTP/2 通常比 4 个子域名 + HTTP/1.1 快 15–30%
除非你明确需要跨源隔离（如第三方 CDN），否则 HTML 中所有静态资源应指向同一主域名（如 https://example.com）。
<link rel="preload"> 是让多路复用“立刻干活”的最简单手段
浏览器解析 HTML 是线性的，遇到 <script src="app.js"> 才发起请求；而 <link rel="preload"> 可在解析早期就触发资源获取，抢占复用通道带宽：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
<link rel="preload" href="/styles.css" as="style"> <link rel="preload" href="/main.js" as="script"> <link rel="preload" href="/hero.jpg" as="image">
-
as属性必须填写，否则浏览器无法设置正确请求头（如Accept）和缓存策略 - 不要 preload 非关键资源（如页脚广告 JS），会挤占首屏资源带宽
- preload 不会阻塞 HTML 解析，但会提升资源在复用流中的调度优先级
- 注意：preload 不等于执行，
<script>仍需显式引入才能运行
服务端推送（Server Push）已基本弃用，别在 HTML 里预留坑
HTTP/2 规范曾定义 PUSH_PROMISE 帧用于服务端主动推送资源，但实践中问题太多：
- 浏览器无法取消推送，即使资源已在缓存中，也会被重复接收
- 推送资源无法参与 HTML 解析时的优先级决策（比如用户只滚动到页面中部，却推了整个 footer.js）
- 主流浏览器（Chrome 96+、Firefox 90+）已默认禁用 Server Push
- 如果你在 HTML 注释里写了类似
<!-- push /logo.svg -->或依赖 Nginxhttp2_push指令，现在该删了
真正可控的方式，还是靠 HTML 显式声明 + 服务端支持 Cache-Control 和 ETag，让多路复用只传增量。
多路复用不是魔法——它不会自动合并请求，也不会猜测你要什么资源。它的价值，取决于你是否让 HTML 成为清晰、集中、可预测的资源调度图。最容易被忽略的一点：检查你的 HTML 里有没有隐藏的 http:// 协议链接，或混合了 www 与非 www 域名，这种看似微小的不一致，会让整个复用通道从第一字节就开始降级。
