@import一定慢，因其强制同步阻塞解析：浏览器必须等被导入CSS下载并解析完才能继续，导致串行加载、DOMContentLoaded延迟、FOUC及Lighthouse报错；嵌套2层以上常增200ms+延迟，而<link>可并行下载且支持预加载。
@import 本身无法真正“解决”加载延迟——它天生就是阻塞的。想让样式快，就得绕开它，或者严格限制它的使用场景。
为什么 @import 一定会慢？
浏览器解析到 @import 时，必须停下当前 CSS 的解析，等被导入的文件下载、解析完，才能继续。这不是 bug，是 CSS 规范强制要求的同步行为。
常见错误现象包括：DOMContentLoaded 延迟、首屏白屏或 FOUC（无样式内容闪烁）、Lighthouse 报 “Eliminate render-blocking resources”。
- 嵌套 2 层以上（A.css →
@importB.css →@importC.css），DOMContentLoaded常增加 200ms+（弱网更明显） -
@import在<style>标签里比外链 CSS 更晚执行，且无法被浏览器预加载器发现 - 跨域
@import会触发额外 CORS 预检，进一步拉长等待时间
用 <link rel="stylesheet"> 替代是最直接有效的办法
把原本写在 CSS 文件里的 @import url("button.css"); 拿出来，放到 HTML 的 <head> 里：
<link rel="stylesheet" href="button.css"> <link rel="stylesheet" href="header.css"> <link rel="stylesheet" href="theme-dark.css">
这样浏览器在解析 HTML 时就能并行发起请求，支持 DNS 预解析、TCP 预连接，HTTP/2 或 HTTP/3 下效果更明显。
立即学习“前端免费学习笔记（深入）”；
- 多个
<link>之间互不阻塞，不像@import那样串成一条线 - 可以加
media属性做条件加载，比如<link rel="stylesheet" href="print.css" media="print">，浏览器不会下载非匹配设备的样式 - 关键样式（如首屏字体、颜色、布局）建议内联进
<style>，控制在 2–3KB 内
真要用 @import？只在非关键、静态、末尾场景下
如果旧项目无法重构，至少守住三条底线：
- 只在 CSS 文件最末尾使用，例如
@import "print.css" print;，确保不影响主渲染路径 - 绝对不要在
<style>标签里写@import—— 它比外链更晚执行，且完全逃不出解析阻塞 - 禁止动态路径，比如
@import url("theme-" + $color + ".css");；Sass/Less 编译后也必须输出静态 URL
注意：@import 加媒体查询（如 @import url("mobile.css") screen and (max-width: 767px);）虽能跳过不匹配设备的下载，但它仍会阻塞同文件后续规则的解析，且无法被 rel="preload" 提前触发。
构建工具里 @import 的实际影响常被误判
Webpack/Vite 项目中，你写的 @import 很可能在编译阶段就被合并或转成了 <link>，真正影响性能的往往是误操作：
- 没开启 CSS 提取（如
mini-css-extract-plugin），导致样式被打包进 JS，拖慢 JS 解析 - 把大量第三方 UI 库的 CSS 用
@import堆在入口main.css里，单文件过大 - 开发时改了
@import路径，触发全量重编译，热更新变慢
Chrome DevTools 的 Network 面板里，按 “Start Time” 排序看 CSS 请求是否纵向串行排列，就能快速确认是不是 @import 在卡住加载链。
真正容易被忽略的点是：不是所有 @import 都在代码里明写着——有些框架或组件库内部用了它，得查构建产物或源码。
