能，并发加载需同域名、启用http/2/3且浏览器支持；多路复用使多个link并行收发，但拆分不当会增加解析开销、降低缓存命中率，应按需拆分并配合preload与内联关键css。
多个在HTTP/2下真能并发加载吗
能，但前提是所有指向同域名、服务端启用了HTTP/2（或HTTP/3），且浏览器支持。HTTP/2的多路复用机制允许单个TCP连接上并行收发多个请求帧，link标签触发的CSS请求不再像HTTP/1.1那样排队等待——Network面板里看到的多个Content Download时间重叠，不是错觉，是真实并发。
常见错误现象：明明开了HTTP/2，却看到十几个CSS请求的TTFB依次升高。大概率是域名不统一（比如混用了static1.example.com和cdn.example.com），导致浏览器为每个子域新建连接，复用失效。
- 用Chrome DevTools的Network面板过滤
Protocol列，确认全是h2或h3 - 检查每个
link的href是否解析到同一主域（不含子域差异） - 避免在HTML中主动做“域名分片”，这是HTTP/1.1时代的过时操作
为什么多个不一定比合并CSS快
HTTP/2解决了网络层并发瓶颈，但没消除其他开销：每个link仍需独立的HTTP头部、TLS会话恢复（若未复用）、缓存键（URL）不同导致CDN缓存命中率下降；更重要的是，每个CSS文件都要走完整解析、样式计算、层叠应用流程，内存和CPU成本是叠加的。
使用场景：拆分只在逻辑隔离明确、加载时机差异大时有价值（如主题CSS、后台模块CSS），而不是单纯为了“看起来并发”。
- 移动端弱网下，10个5KB的CSS比1个50KB的CSS多出近10倍RTT延迟
-
@import在任一CSS文件内部出现，会打断并行链，退化为串行加载 - 构建工具（如Webpack、Vite）生成的CSS chunk若未配置
splitChunks策略，容易产出大量小文件，反而拖累
如何让多个真正发挥HTTP/2优势
关键不在“多”，而在“调度得当”：让浏览器尽早发起请求、减少空闲窗口、避免隐式阻塞。
常见错误现象：把link写在一堆同步script后面，结果浏览器卡在JS下载上，CSS请求压根没机会发出。
- 关键CSS必须内联在
中，非关键CSS用<link rel="preload" as="style">提前拉取 - 避免
link[rel="stylesheet"]后紧跟同步script——规范强制等待样式加载完成才继续下载该脚本 - 第三方资源（如字体、统计JS）改用
preconnect建立连接，再配合prefetch预取，别挤占主域复用通道 - 验证时看Initiator：preload应为
preload，prefetch应为prefetch，parser发起的才是HTML自然解析触发的
最容易被忽略的兼容性陷阱
HTTP/2是传输协议，但浏览器行为还受HTML解析规则约束。比如IE完全不支持preload，而某些Android WebView对crossorigin属性处理异常，会导致prefetch静默失败。
性能影响常藏在细节里：一个漏掉crossorigin的link rel="prefetch" as="font"，在Safari下根本不会发请求；而media="(print)"写的link，浏览器照常下载，只是延迟应用——这会悄悄吃掉带宽。
- 所有
href用绝对路径或根相对路径（如/css/theme.css），避免子路由下解析失败 -
as值必须精确匹配资源类型：as="style"不能写成as="css"，否则降级为as="document" - 不要依赖
prefetch保证下一页秒开——它只进HTTP缓存，不执行JS、不恢复状态、不预渲染
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
