@import 会阻塞渲染和后续 CSS 解析，因其同步加载机制导致瀑布式请求、延迟首屏绘制，且无法被预加载器提前发现；应优先使用 并行加载或 preload。
@import 会阻塞渲染和后续 CSS 解析
是的，@import 在 CSS 文件中使用时，会触发同步、阻塞式加载：浏览器必须下载并解析完被 @import 引入的 CSS 文件后，才会继续解析当前文件中其后的规则，也会延迟页面渲染（尤其是首次绘制）。这和 <link rel="stylesheet"> 的并行加载行为明显不同。
@import 的加载时机取决于书写位置
@import 必须出现在 CSS 文件最顶部（在任何实际样式规则之前），否则会被忽略；一旦出现，它会在当前样式表解析到该行时立即发起网络请求，并且阻塞后续 CSS 规则的解析与应用。如果链式嵌套（A.css @import B.css，B.css 又 @import C.css），阻塞会逐层传递，形成“瀑布流”加载。
- 放在
<style></style>标签内？同样阻塞，且无法利用预加载器（preloader）提前发现资源 - 写在
@media查询内部？仅当媒体条件匹配时才触发加载，但仍会阻塞该媒体块内的后续解析 - 用 JS 动态创建
<style></style>并注入含@import的文本？仍按 CSS 规范执行阻塞逻辑，不改变本质
对比 link 和 @import 的关键差异
核心区别不在“是否下载”，而在于是否可并行发现与加载”：
-
<link rel="stylesheet" href="a.css">：HTML 解析阶段即被预加载器捕获，多个<link>可并行下载 -
@import url("a.css");：CSS 解析器运行到这一行才发起请求，前一个@import未完成，后一个不会开始（即使 URL 不同） - 工具如 Lighthouse 会将含
@import的 CSS 标记为“渲染阻塞资源”，且无法通过preload提前干预
/* ❌ 链式阻塞示例：b.css 必须等 a.css 完全加载解析后才开始请求 */
@import url("a.css");
@import url("b.css"); /* 这行要等到 a.css 处理完才执行 */现代项目中应避免在主样式表中使用 @import
除非用于特定场景（如主题切换时按需加载、CSS-in-JS 库内部封装、或兼容极老构建工具的 hack），否则生产环境应禁用 CSS 文件内的 @import。构建工具（如 Webpack、Vite）通常将 @import 提前编译为内联内容或转为 <link>，但若直接部署未处理的 CSS 文件，风险仍在。
立即学习“前端免费学习笔记（深入）”；
- 替代方案：用 HTML 的
<link>并行加载，或用preload提前拉取关键 CSS - 注意：CSS @import 支持 media 属性（
@import url("print.css") print;），但即便带 media，仍会发起请求（只是不立即应用），对性能仍有影响 - 浏览器兼容性不是问题，问题是它太“老实”——严格按规范一步步来，而现代性能优化恰恰需要打破这种顺序依赖
真正容易被忽略的是：哪怕只在一个深埋的 theme.css 里写了单行 @import，它也可能拖慢整个首屏样式树的构建。检查最终上线的 CSS 内容，比看源码构建配置更直接有效。
