绝大多数情况下不该用@import，因其阻塞串行加载导致渲染延迟；仅适合CSS内媒体查询条件引入、维护遗留代码或构建时已预编译合并的场景。
什么时候该用 @import 而不是 <link>
绝大多数情况下，不该用 @import。它会阻塞并串行加载样式，导致 CSS 渲染延迟，尤其在多层嵌套时（比如 A.css @import B.css，B.css 又 @import C.css），浏览器必须等前一个下载解析完才发起下一个请求。而 <link rel="stylesheet"> 是并行加载的，性能优势明显。
真正适合 @import 的场景极少，典型的是：
- 需要在 CSS 文件内部做条件引入（比如媒体查询内动态加载主题）
- 维护遗留代码时被迫兼容已有
@import链路 - 构建流程中已将所有
@import提前编译合并（此时它只存在于源码，不出现在最终 HTML 中）
@import 的语法细节和常见写错点
@import 必须出现在样式表最顶部（在任何实际规则之前），且不能放在 @media 外部的嵌套块里。下面这些写法都会失效或报错：
-
@import url("theme.css") screen and (min-width: 768px);→ 错误：媒体查询必须包裹整个@import，不能只修饰 URL -
body { color: red; } @import "reset.css";→ 错误：规则之后不能再有@import -
@import 'https://fonts.googleapis.com/css2?family=Roboto';→ 可能失败：部分浏览器对跨域@import有严格限制，且无CORS头时会被拒绝
正确写法只有两种主流形式：
立即学习“前端免费学习笔记（深入）”；
@import "base.css";
@import url("print.css") print;
和 <link> 混用时的优先级陷阱
@import 引入的样式，其层叠优先级与写在相同位置的普通规则一致，但加载时机晚于同级 <link>。这意味着：
- 如果 HTML 中先
<link href="a.css">，a.css 里又@import "b.css"，那么 b.css 的规则会后解析，可能覆盖 a.css 中同选择器的声明 - 但若 b.css 和 c.css 都通过
<link>引入，它们的顺序就完全由 HTML 中<link>标签顺序决定，和文件内部内容无关 - 更隐蔽的问题：某些构建工具（如早期 webpack css-loader）默认把
@import当作依赖提前提取，结果运行时反而没了“导入”行为——实际生效的是打包后的单文件
现代项目里基本可以忽略 @import
PostCSS、Sass、Less 等预处理器都支持自己的 @import（如 Sass 的 @use / @forward），它们在构建阶段处理，不产生运行时请求。而原生 CSS 的 @import 在 HTTP/2 和现代打包流程下已无存在必要。真正要注意的反而是：别在审查元素里看到某个样式来自 imported stylesheet 就以为它是动态加载的——那往往只是 DevTools 对源映射的显示方式，实际早已被合并。
