@import 不推荐使用，因其同步阻塞加载、无法被预加载器识别、导致串行瀑布请求，并存在旧版ie兼容问题及构建工具支持不足等缺陷。
为什么 @import 在 CSS 中不推荐使用
@import 本质是同步阻塞加载，浏览器必须先下载并解析完导入的 CSS 文件，才能继续处理后续样式表或渲染页面。它没有并行加载能力，尤其在多层嵌套时（比如 @import 里再 @import），会形成串行瀑布，显著拖慢首屏时间。
更关键的是，@import 在 CSS 文件中声明时，**无法被预加载器（preload scanner）识别**——浏览器解析 HTML 时只扫描 <link rel="stylesheet">，而忽略 CSS 内部的 @import，导致资源发现延迟，进一步恶化加载性能。
<link> 与 @import 的加载时机差异
根本区别不在语法，而在执行阶段：<link> 是 HTML 解析阶段触发的资源获取；@import 是 CSS 解析阶段才触发的二次请求。
-
<link rel="stylesheet" href="a.css">：HTML 解析到即发起请求，可与 HTML 并行下载 -
@import url("b.css");（写在a.css中）：必须等a.css下载、解析完成，才开始请求b.css - 若
a.css本身由@import引入（如写在style.css里），则加载链条变成：HTML →style.css→ 解析 →a.css→ 解析 →b.css
实测中，三层 @import 嵌套比等价的三个 <link> 多出 300–800ms 首字节延迟（取决于网络和文件大小）。
立即学习“前端免费学习笔记（深入）”；
兼容性与维护风险
@import 虽然支持所有现代浏览器，但在旧版 IE（尤其是 IE6–IE8）中存在多个隐性问题：
- IE6/7 不支持媒体查询条件写在
@import后（@import url(x.css) screen and (min-width:768px);会被完全忽略） - IE 中
@import必须位于 CSS 文件最顶部，前面不能有任何字符（包括 BOM、注释、空行），否则整个规则失效 - 构建工具（如 Webpack、Vite）默认不内联
@import，容易造成运行时额外 HTTP 请求，而<link>更易被提取、压缩、预加载控制
另外，CSS-in-JS 或模块化方案（如 CSS Modules）基本不支持 @import，强行使用会破坏作用域隔离和热更新逻辑。
什么情况下还能用 @import
仅限两个真实可行的场景，且需明确知道代价：
- 在已通过
<link>加载的基础 CSS 文件内部，做条件化引入（如@import url("print.css") print;），此时不影响屏幕样式加载 - 开发阶段临时调试，快速复用他人 CSS 片段（例如
@import url("https://cdn.example.com/reset.css");），但上线前必须转为<link>或内联合并
注意：@import 不支持 as 别名、type 类型提示、crossorigin 属性等现代 <link> 支持的控制能力，扩展性天然受限。
/* ❌ 不推荐：嵌套、阻塞、不可控 */
@import url("base.css");
@import url("theme.css") (prefers-color-scheme: dark);
<p>/<em> ✅ 推荐：HTML 中显式声明，支持预加载和媒体查询 </em>/
<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="theme.css" media="(prefers-color-scheme: dark)"></p>实际项目里，只要构建流程可控，就该把所有 @import 拆出来，改用 <link> + 构建时合并或按需加载。真正难处理的，往往是第三方 UI 库自带的 @import 链，这时候得靠 PostCSS 插件（如 postcss-import）提前展开，而不是放任它跑在浏览器里。
