不值得。HTTP/2 Server Push 已被 Chrome 110+、Firefox 100+、Safari 16.4+ 默认禁用或移除，配置无效且增开销；可靠替代是 preload + early hints（需服务端支持），HTML 应精简结构、避免冗余嵌套与 table 布局，并确保 <meta charset> 置于 head 开头。
HTTP/2 Server Push 还值得用吗？
不值得。HTTP/2 Server Push 在 2026 年已基本被主流浏览器弃用——Chrome 110+、Firefox 100+、Safari 16.4+ 均默认禁用或完全移除支持。你看到的 server push 配置，大概率不会触发任何推送行为，反而可能因冗余响应头增加 TLS 握手开销。
真正起效的是 preload + early hints（HTTP/1.1 状态码 103），但后者需服务端明确支持（如 Nginx 1.21.4+ 或 Cloudflare Workers），且仅对首屏关键资源有效。
- 别在 Nginx 配置里写
http2_push，它已失效 - 若用 Node.js（如 Express），
res.push()调用会静默失败，无报错也无效果 - 想“提前送资源”，唯一可靠路径是：
<link rel="preload" href="main.css" as="style">，且必须带as属性
HTML 结构怎么配合 HTTP/2 多路复用？
HTTP/2 本身不关心 HTML 写法，但它放大了结构低效的代价：多路复用让大量小文件并行传输更高效，可如果 DOM 树太深、节点太多，浏览器解析和构建成本反而成为瓶颈，压倒传输优势。
重点不是“用不用 HTTP/2”，而是避免让它暴露你的结构缺陷：
立即学习“前端免费学习笔记（深入）”；
- 删掉无意义嵌套：
<div class="wrapper"><div class="container"><div class="content">→ 直接用<main class="content"> - 禁用
<table>布局：其 DOM 节点数通常是等效flex的 3–5 倍，HTTP/2 传得快，但浏览器渲染更慢 -
<meta charset="utf-8">必须放在<head>最开头，否则浏览器会先按默认编码（如 ISO-8859-1）解析几百字节，再重读，白白浪费一次解析
静态资源路径写法影响 HTTP/2 效果吗？
不影响传输效率，但影响缓存复用与连接复用粒度。HTTP/2 的多路复用基于 TCP 连接，而浏览器对不同域名的资源会建立独立连接——哪怕只差一个子域名。
常见坑点：
- 把
css/、js/、img/分到static.example.com、cdn.example.com、assets.example.com—— 实际建了 3 条 TCP 连接，失去 HTTP/2 连接复用价值 - 用相对路径
./styles/main.css没问题，但绝对路径写成https://example.com/styles/main.css会导致跨域预检（如果没配 CORS），反而拖慢 - CDN 域名建议统一为
static.example.com，所有静态资源走同一 host，最大化连接复用
HTTP/2 下还要不要合并 JS/CSS 文件？
不需要，甚至有害。HTTP/2 的多路复用消除了 HTTP/1.1 下“减少请求数”的首要动机；合并反而带来三个问题：
- 缓存失效放大：改一行 CSS，整个
bundle.css缓存全废 - 首屏阻塞加剧：非关键 CSS 被打包进关键路径，延迟 FCP
- JS 执行依赖混乱：多个
defer脚本合并后，无法保证执行顺序，容易报ReferenceError
正确做法是按加载时机拆分：
- 首屏必需的 CSS → 内联到
<head>（≤10KB） - 非首屏 CSS → 单独文件 +
<link rel="stylesheet" media="print" onload="this.media='all'">异步加载 - 业务主逻辑 JS → 拆成
app.js（defer）、vendor.js（defer），保持独立文件
HTTP/2 不是万能加速器，它只是把“传输层”变快了，而 HTML 结构、资源加载策略、浏览器解析行为这些环节，依然由你写的代码决定。最容易被忽略的，其实是 DOM 深度和 <meta charset> 的位置——它们不产生网络请求，却直接卡住整个渲染流水线。
