link标签会触发并行下载，前提是都写在head中且无隐式依赖；@import则强制串行阻塞，必须等父样式表下载解析完才发起下个请求，导致首屏延迟可达800ms+。
多个会触发并行下载吗
会，但前提是它们都写在
里且没有隐式依赖。浏览器遇到每个就立即发起一个HTTP请求，彼此不等待——这是和@import最本质的性能差异。常见错误现象：明明写了三个，Network面板却看到串行加载。大概率是因为其中某个CSS文件内部用了@import，或者服务器启用了HTTP/2但配置了优先级策略，把样式请求人为降权。
- 确保所有都在内，且顺序合理（基础样式靠前、覆盖样式靠后）
- 避免在某一个CSS里写@import url("xxx.css")——这会让那个xxx.css变成“第二梯队”，延迟数百毫秒
- HTTP/2下并行数由服务端帧调度控制，不是客户端能完全决定的；若发现并行不足，先查服务器设置而非改HTML
rel="preload"和rel="stylesheet"混用时的并发行为
两者不冲突，但必须配对使用，且不能替代。preload只下载，不解析；stylesheet才真正注入CSSOM。
容易踩的坑是以为写了
就不用再写<style>或<link rel="stylesheet">——结果字体或关键CSS根本没生效。 <ul> <li><code>rel="preload"必须带<code>as="style"，否则浏览器当普通资源处理，不会提升优先级 <li>同一资源不能既<code>preload又<code>stylesheet，否则可能重复请求（尤其跨域时CORS头不一致） <li>preload的<code>href路径必须和后续stylesheet的<code>href完全一致（含查询参数），否则缓存不命中 <H3>link标签位置错误如何悄悄降低并行度 <p>写在<body>里的<link rel="stylesheet">，浏览器通常仍会加载，但早期资源发现机制失效——这意味着预加载、DNS预解析等优化全丢，间接拉低整体并行效率。 <p>更隐蔽的问题是：某些CDN或代理层会根据请求发起时机做QoS调度，晚于<head>阶段的请求默认被降权。 <ul> <li>所有<link>必须放在<head>内，哪怕只是<code>rel="icon"或<code>rel="preconnect" <li>不要用JS动态插入<link>来“绕过”位置限制——虽然能生效，但失去浏览器早期资源发现能力 <li>验证方式：打开DevTools → Network → 切到“Waterfall”视图，看各<link>请求的Start Time是否集中在HTML解析初期 <H3>同域名下大量link标签是否触发连接数瓶颈 <p>会，但只在HTTP/1.1环境下明显。现代浏览器对同域名HTTP/2连接默认复用，所以10个<link>通常走同一个TCP连接；而HTTP/1.1下，Chrome默认最多6个并发连接，超出的<link>会被排队等待。 <p>这不是HTML写法问题，而是协议层限制。构建阶段合并CSS比堆一堆<link>更有效。 <ul> <li>HTTP/1.1项目中，<code>link数量建议控制在3–5个以内，非关键CSS用<code>media属性条件加载 <li>HTTP/2项目中，重点不在数量，而在资源优先级——用<code>rel="preload"显式声明首屏关键CSS <li>不要为每个组件单独配一个<link>，尤其是微前端场景；应由主应用统一管理样式加载流 真实世界里，并行下载数不是由HTML里写了几个<link>直接决定的，而是浏览器解析时机、服务端协议支持、网络中间件策略三者共同作用的结果。最容易被忽略的是：你以为自己在控制下载，其实只是在声明意图；真正调度权，始终在浏览器和服务器手里。 </style>
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
