@import会让首屏渲染变慢300–800ms，因其是运行时串行加载，浏览器需等主CSS下载解析到该行才发起下个请求，HTML预加载器无法识别，导致瀑布链、FCP延迟、关键路径拉长，且HTTP/2也无法绕过语法限制。
为什么@import会让首屏渲染变慢300–800ms
因为@import是运行时串行加载，浏览器必须等主CSS文件下载完成、开始解析、读到@import那行，才发起下一个请求。HTML预加载器完全看不见它，而<link>在解析HTML第一行就并发拉资源。
常见错误现象：Network面板里看到明显的瀑布链——main.css → reset.css → components.css；弱网下FCP延迟直接多出半秒以上；哪怕被导入的是1KB的reset.css，也得排队等前面文件整个传输+解析完。
- HTTP/2虽支持多路复用，但
@import顺序执行是语法硬限制，无法提前预加载 - 嵌套两层
@import= 强制三次网络往返，关键渲染路径被拉长 - Vite默认不处理原生CSS中的
@import，它照常发运行时请求，不会警告也不会内联
SCSS/Less里的@import和CSS原生@import根本不是一回事
你在_button.scss里写@import "vars"没问题，那是编译期合并；但上线后如果最终生成的main.css里还藏着一行@import url("legacy-theme.css")，这行才是真正在拖慢首屏的罪魁祸首。
构建工具容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
- Webpack同时启用
css-loader和postcss-import时，默认行为可能冲突，导致部分@import被忽略或重复打包 - 第三方UI库输出的CSS里混入了原生
@import，人眼很难发现，尤其在压缩后 -
<style scoped>里用@import，样式仍是全局的——它本质是发起新请求，不参与作用域隔离
媒体查询里的@import其实并不“懒”
@import url("print.css") print;看着只在打印时生效，但浏览器仍会在初始HTML解析阶段下载该文件。除非把它塞进一个不匹配的@media块里（比如@media (max-width: 0) { @import "x.css"; }），但这种写法在IE、旧Safari里基本失效。
真正安全的条件加载方式：
- 用
<link rel="stylesheet" media="print" href="print.css">，浏览器明确知道不参与首屏渲染 - 动态JS加载：
if (window.matchMedia('(prefers-color-scheme: dark)').matches) import('./dark.css') - 构建时按环境变量拆包，而不是靠运行时
@import做条件判断
替换@import不是简单删掉再加<link>
直接把@import "reset.css"; @import "layout.css";换成两个并列<link>，大概率会破坏层叠顺序——reset.css本该最优先，但HTML中后写的<link>反而覆盖了它。
迁移要点：
- 先提取所有
@import路径，按出现顺序整理成依赖链 - 重置类（
normalize、reset）和基础变量必须放在<head>最前面的<link> - 组件样式按实际DOM结构深度排序，容器样式要早于子组件
- 非首屏样式（如
print.css、dark.css）必须带media属性，否则仍阻塞渲染
最容易被忽略的点：第三方库打包产物里的@import往往藏在压缩后的CSS里，靠肉眼检查不可靠，得用构建插件（如postcss-reporter）自动扫描输出文件。
