有帮助，但仅当多个CSS文件通过同一HTTP/2连接并行加载时才体现；单个CSS文件无法利用多路复用，且必须HTTPS、避免跨域、禁用@import、合理拆分与预加载，并确认Protocol为h2。
HTTP/2 多路复用对 CSS 加载真有帮助吗？
有，但仅当 CSS 文件被拆成多个 link 请求、且都走同一 HTTP/2 连接时才体现优势。单个大 style.css 文件无论 HTTP/1.1 还是 HTTP/2，都只占一个流——多路复用压根没机会介入。
常见错误现象：Network 面板里看到多个 CSS 请求仍排队（TTFB 高、Start Time 错开），其实是服务端未启用 HTTP/2，或浏览器降级到了 HTTP/1.1（比如 localhost 未配 HTTPS）。
- 确认是否真在用 HTTP/2：Chrome DevTools →
Network表头右键勾选Protocol，所有请求应显示h2 - 必须 HTTPS：HTTP/2 在主流浏览器中强制要求 TLS，
http://域名下永远 fallback 到 HTTP/1.1 - 避免跨域 CSS：不同域名 = 不同连接 = 失去多路复用聚合优势；
cdn.example.com/style.css和app.example.com/base.css不会共享流
拆分 CSS 时怎么避免阻塞渲染？
拆太多 link 标签，反而触发更多阻塞解析的 CSS 资源加载；拆太少，又浪费多路复用。关键不是“数量”，而是“加载时机”和“关键性”。
使用场景：首屏强依赖的样式（如按钮、导航栏）必须内联或提前加载；非首屏组件（如模态框、图表）可延迟加载。
立即学习“前端免费学习笔记（深入）”；
- 把首屏 CSS 提取为
<style>内联到<head>，彻底绕过网络请求 - 剩余 CSS 按路由/组件拆成小文件，用
link rel="preload" as="style" onload="this.rel='stylesheet'"异步加载（注意：不能直接写rel="stylesheet"，否则仍阻塞） - 禁用
@import：它会强制串行加载，HTTP/2 下也破坏多路复用效果；Webpack/Vite 构建时确保css-loader的importLoaders不引发深层@import链
HTTP/2 下 CSS 文件还能压缩和合并吗？
能，但目的变了：不再是为了减少请求数（HTTP/2 已解决），而是为了降低 TLS 握手后首字节传输量、提升 gzip/Brotli 压缩率。
参数差异：gzip 对 1 个 100KB 文件的压缩率，通常高于 10 个 10KB 文件分别压缩之和；Brotli 尤其明显。
- 保留构建时 CSS 合并（如 Webpack 的
splitChunks.chunks: 'all'），但输出为 2–3 个逻辑包（base.css、theme.css、async-components.css），而非 1 个巨无霸 - 开启 Brotli 压缩（Nginx：
brotli on;），比 gzip 平均再省 15% 体积，对多路复用后的并发传输更友好 - 慎用
Cache-Control: immutable：CSS 带哈希指纹就足够长效缓存，加immutable可能让更新失效（浏览器可能不检查新版本）
HTTP/2 服务器推送（Server Push）还值得用吗？
不值得。现代浏览器（Chrome 96+、Firefox 90+）已弃用 HTTP/2 Server Push，Nginx/Apache 默认关闭，Vite/Next.js 等工具链也不再生成 PUSH_PROMISE。
容易踩的坑：有人还在 Nginx 配置里写 http2_push /style.css;，实际无效，且可能干扰资源优先级调度。
- 替代方案是
<link rel="preload">，由 HTML 主动声明高优资源，语义清晰、兼容性好、可控性强 - 如果用了 CDN（如 Cloudflare），确认其“HTTP/2 Server Push”功能已关闭，避免配置残留干扰
- 真正影响 CSS 加载效率的，是 TCP 连接复用质量、TLS 1.3 握手速度、以及服务端响应头里的
Priority字段（部分支持），不是推送
HTTP/2 对 CSS 的优化，核心不在“推”或“拆”，而在让每个 CSS 请求都轻、快、可预测。最容易被忽略的是：你根本不知道自己有没有真正跑在 HTTP/2 上——先看 Protocol 列，再调其他。
