不要在CSS中使用@import，因为它会阻塞并串行加载样式资源，导致首屏渲染延迟数百毫秒，尤其在弱网或高延迟CDN下更明显；应通过构建工具（如Vite/Webpack）在编译期解析并扁平化@import，最终输出为多个标签或内联关键CSS。
为什么不要在CSS里用@import
因为@import会阻塞并串行加载CSS资源，浏览器必须下载、解析完前一个@import引入的文件，才能继续处理后续样式，哪怕它只是个空文件。实际项目中，一个@import可能让首屏渲染延迟几百毫秒——尤其在弱网或高延迟CDN场景下更明显。
常见错误现象：Network面板里看到多个CSS请求排成一条竖线；Lighthouse提示“Render-blocking resources”；DOMContentLoaded时间异常偏高。
- 所有
@import都应在构建阶段被提取、合并、内联或拆分为<link rel="stylesheet"> - 如果用Webpack/Vite，确保
css-loader或postcss-import只在开发期解析@import，产出时已扁平化 - 禁止在
.css文件里写@import url("xxx.css")，特别是跨域名或深层嵌套
Vite/Webpack里怎么安全地“模拟”@import行为
构建工具本身不运行CSS，所以真正的@import语义必须由loader提前处理。关键不是“能不能用”，而是“谁来解析、何时解析、是否可复现”。
使用场景：组件级CSS复用（比如button.css里@import "./vars.css"）、主题变量抽离。
立即学习“前端免费学习笔记（深入）”；
- Vite默认启用
postcss-import，直接写@import "./vars.css"即可，但路径必须是相对路径或别名（如@/styles/vars.css） - Webpack需显式配置
postcss-loader+postcss-import，且css-loader的importLoaders要≥1 - 避免在
@import路径里拼接变量或动态字符串——PostCSS不支持运行时计算 - 注意
@import顺序：它按源码书写顺序解析，不是按文件系统顺序
替代@import的高性能方案有哪些
目标不是“去掉@import”，而是让样式依赖关系可预测、可分割、可缓存。真正影响性能的是加载方式和产物结构，不是语法本身。
- 用
<link rel="preload" as="style" href="main.css">提前触发关键CSS下载 - 把基础变量、重置样式、工具类打包进
base.css，用<link>同步加载；业务模块CSS用rel="stylesheet" media="print" onload="this.media='all'"异步加载 - CSS-in-JS方案（如Linaria、Vanilla Extract）在构建期生成原子化CSS，天然规避
@import链路 - PostCSS插件如
postcss-preset-env可将@custom-media等新语法转译，无需手写@import
构建后CSS体积和HTTP请求数怎么平衡
一个@import看似省事，实则让构建工具失去优化主动权——它无法判断哪些样式可Tree-shake，哪些媒体查询可合并，哪些重复规则该剔除。
典型坑：开发时用@import引入几十个小文件，构建后仍保持原样，导致20+个link标签；或者误以为“CSS拆得越细越好”，结果HTTP/1.1下请求爆炸。
- HTTP/2环境下，单页
<link>数量控制在5–8个较稳妥；HTTP/1.1建议合并为1–2个关键CSS + 异步加载非关键部分 - 用
critters（Vite插件）或critical（Webpack）自动提取首屏关键CSS并内联，其余惰性加载 - 检查最终HTML里有没有
@import残留——构建后CSS文件里出现@import，说明loader没生效或配置错位
真正难的不是写对一行@import，而是让整个样式依赖图在构建期可见、可控、可验证。很多人调了半天postcss-import路径，却忘了看输出目录里CSS是不是真的没了@import。
