@import会卡死关键渲染路径，因其被浏览器预加载扫描器忽略，必须等主CSS下载解析到该行才发起请求，形成语法级串行阻塞；两层嵌套实测多延400–750ms。
为什么@import会卡死关键渲染路径
因为浏览器预加载扫描器（preload scanner）完全无视 CSS 文件里的 @import，它只认 HTML 中的 <link rel="stylesheet">。这意味着：主 CSS 文件必须完整下载、开始解析、逐字读到 @import url("a.css") 这一行，才能发起对 a.css 的请求；而如果 a.css 里又写了 @import url("b.css")，那 b.css 就得等 a.css 下载+解析完才启动——这不是“慢一点”，是语法级的硬性串行阻塞。
为什么能并发而@import只能排队
<link> 在 HTML 解析第一行时就被预加载器捕获，并发发出请求；@import 是 CSS 解析阶段的同步指令，浏览器必须暂停当前样式表解析，等导入资源就绪后才能继续。这导致：
- Network 面板里多个
@import请求排成竖线，实测两层嵌套比等价<link>多出 400–750ms 首字节延迟 - 即使开了 HTTP/2，也无法绕过语义顺序——多路复用救不了执行逻辑
-
@import后面的样式规则（包括本地声明）全部被挂起，CSSOM 构建停滞
@import在
写在 HTML 的 <style></style> 标签里，@import 仍走 CSS 解析路径，不享受 parser 预加载；放进 Shadow DOM 的 shadowRoot.innerHTML = '<style>@import url(x.css)</style>'，则：
- 路径按 HTML 文档 URL 解析，不是组件 JS 所在位置，极易 404
- 返回 404/500 时，整个
<style></style>块被浏览器静默丢弃，控制台零提示 - 阻塞 Shadow DOM 渲染，首屏自定义元素白屏 300–600ms
- SSR 和 HMR 完全失效，构建工具也无从处理
构建产物里残留@import才是真凶
你在 SCSS 里写 @import "vars" 是安全的——那是编译期行为；但上线后拖慢首屏的，往往是打包生成的 main.css 末尾藏着一行 @import url("legacy-theme.css")。原因包括：
- Webpack 的
css-loader默认保留原生@import，不内联也不警告 - Vite 默认不处理它，照常发运行时请求
- 第三方 UI 库的 CSS 输出可能带
@import，CI 流程没做grep -r "@import" src/ --include="*.css"就直接上线 - 媒体查询写成
@import url("dark.css") (prefers-color-scheme: dark)，多数浏览器不生效，还白下一次
真正的坑不在“用了没”，而在“你以为删了，其实还在”。哪怕只有一处 @import 残留，整个关键渲染路径的并行能力就被彻底锁死。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
