HTTP/2多路复用不消除CSS拆分必要性，而是重构拆分逻辑：关键在加载时机与资源受益关系，而非单纯并发能力；首屏样式须内联，非首屏用preload或media懒加载，避免@import串行陷阱。
HTTP/2 多路复用本身不改变 CSS 拆分的必要性，但它改变了「拆多少」「怎么拆」「为什么这么拆」的判断依据——关键不是“能不能并发”，而是“并发之后谁真正受益、谁反而被拖累”。
多路复用不等于零成本并发
HTTP/2 允许 10 个 link 标签在同一个 TCP 连接上并发请求，但每个请求仍要经历：TLS 解密开销、服务端文件读取（小文件多 → 更多磁盘寻道或冷缓存）、帧调度与重组、浏览器样式表解析队列竞争。这些隐性成本在单个大文件里被摊薄，在 10 个小文件里被放大。
- 常见错误现象：
Protocol显示h2，但 LCP 时间没变甚至更差——很可能就是小文件过多触发了服务端 I/O 瓶颈或客户端解析排队 - 使用场景：CDN 缓存命中率敏感的项目（如电商首页），合并后
main.css缓存有效期长；而拆成cart.css+product.css后，任一更新都会让整个样式缓存失效 - 性能影响：Chrome DevTools 的
Network面板中观察Time列，若多个 CSS 的Content Download时间高度重叠但总耗时上升，说明多路复用在“忙但低效”地跑
@import 仍是串行黑洞，哪怕协议是 h2
@import 的加载逻辑由 CSS 解析器控制，和 HTTP 协议层完全解耦。浏览器必须下载并解析完含 @import 的文件，才能发起下一条请求——这和 HTTP/1.1 还是 HTTP/2 无关。
- 常见错误现象：CSS 文件里写
@import url("theme.css")，DevTools 中看到theme.css的请求总在父文件parse完成后才开始，且Protocol显示h2也无济于事 - 正确做法：把所有
@import替换为独立<link rel="stylesheet" href="...">，确保浏览器能原生并发拉取 - 容易踩的坑：Sass/Less 开发时保留
@import无妨，但构建产物里必须展开；否则上线即串行
拆分必须绑定加载时机，而非单纯按文件切
HTTP/2 让“多文件并行”变得可行，但没解决“哪些样式该早加载、哪些可以晚”的问题。拆分的价值只在配合加载策略时才释放。
立即学习“前端免费学习笔记（深入）”；
- 首屏强依赖的样式（如导航栏、标题字体、按钮基础框）必须内联进
，绕过任何网络请求——HTTP/2 再快也快不过 DOM 里直接有的字节 - 非首屏样式（如
modal.css、print.css）用<link rel="preload" as="style" onload="this.rel='stylesheet'">异步加载，避免阻塞渲染 - media 属性是天然的懒加载开关：
<link href="print.css" media="print">根本不参与页面初始渲染流程，比任何 JS 动态加载都轻量
真正容易被忽略的是：HTTP/2 下的最优拆分粒度，往往和开发期模块划分不一致。比如 dark-theme.css 和 light-theme.css 逻辑上是两个主题，但若用户切换频繁，合并为 theme.css + JS 动态 class 切换，反而比两个独立文件 + preload 更省带宽和解析开销。
