link 标签加载 CSS 比 @import 更快，因为 link 是 HTML 原生预加载机制，解析时立即并行下载；而 @import 是 CSS 规则，需等父表解析到该行才串行请求，易阻塞且延迟明显。
link 标签加载 CSS 为什么比 @import 更快
<link> 是 HTML 原生资源预加载机制的一部分，浏览器在解析 HTML 时遇到 <link rel="stylesheet"> 就会立即发起 CSS 请求，并行下载；而 @import 是 CSS 规则，必须等父样式表解析到该行才触发后续请求，形成串行阻塞。尤其在多层嵌套 @import 时，加载延迟明显。
- Chrome DevTools 的
Network面板中，<link>请求通常出现在 HTML 解析早期（Timing → Start Time 接近 0ms），@import引入的文件则明显滞后 - 使用
@import会干扰浏览器对关键 CSS 的提取逻辑，可能影响 LCP（最大内容绘制）指标 - 部分旧版 IE 对
@import的解析行为不一致，存在兼容性风险
rel="preload" + as="style" 配合 onload 切换 link 的写法
当需要异步加载非首屏 CSS（如主题切换、打印样式），又不想阻塞渲染，可用 preload 提前拉取资源，再用 JS 控制启用时机。注意不能直接设 rel="stylesheet"，否则仍会阻塞。
<link rel="preload" href="theme-dark.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="theme-dark.css"></noscript>
-
onload回调中需先清空自身（this.onload=null），避免重复执行 - 务必配
<noscript>降级方案，否则禁用 JS 时样式丢失 - 不要对首屏必需 CSS 使用此方式，会导致 FOUC（无样式内容闪烁）
多个 link 标签的顺序与媒体查询影响渲染
CSS 加载顺序直接影响层叠权重和实际生效样式。浏览器按 <link> 在 HTML 中的出现顺序依次解析规则，后加载的样式可覆盖前面同优先级的声明。
- 将基础重置样式（如
reset.css）放在最前，组件样式放中间，主题或覆盖样式放最后 -
media属性为非匹配值（如media="print"）的<link>仍会下载，但不参与屏幕渲染；若希望完全跳过下载，应改用 JS 动态插入 - 避免在
<head>末尾插入大量<link>，可能因网络延迟导致样式表晚于 DOM 就绪，加剧 FOUC
HTTP/2 下多个 link 是否还需合并 CSS 文件
HTTP/2 支持多路复用，单个连接可并行传输多个资源，因此「减少请求数」的收益下降；但合并仍有必要，原因不在连接数，而在缓存粒度与更新成本。
立即学习“前端免费学习笔记（深入）”；
- 把所有 CSS 合成一个大文件，会导致「改一行按钮样式，全量缓存失效」
- 合理拆分：基础框架（
base.css）、业务模块（dashboard.css）、动态主题（theme.css），各自设置不同Cache-Control - 注意
<link>数量过多仍会增加 HTML 体积与解析开销，建议控制在 3–5 个以内
真正容易被忽略的是 integrity 属性的维护成本——每次 CSS 内容变更，都必须同步更新 sha256-xxx 值，否则子资源完整性校验失败，样式直接被丢弃。
