css @import 为什么不推荐使用_对比 link 与 import 的加载方式

@import 不推荐使用，因其同步阻塞加载、无法被预加载器识别、导致串行瀑布请求，并存在旧版IE兼容问题及构建工具支持不足等缺陷。

为什么 @import 在 css 中不推荐使用

@import 本质是同步阻塞加载，浏览器必须先下载并解析完导入的 CSS 文件，才能继续处理后续样式表或渲染页面。它没有并行加载能力，尤其在多层嵌套时（比如 @import 里再 @import），会形成串行瀑布，显著拖慢首屏时间。

更关键的是，@import 在 CSS 文件中声明时，**无法被预加载器（preload scanner）识别**——浏览器解析 html 时只扫描 ，而忽略 CSS 内部的 @import，导致资源发现延迟，进一步恶化加载性能。

与 @import 的加载时机差异

根本区别不在语法，而在执行阶段： 是 HTML 解析阶段触发的资源获取；@import 是 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 嵌套比等价的三个 多出 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 请求，而 更易被提取、压缩、预加载控制

另外，CSS-in-js 或模块化方案（如 CSS Modules）基本不支持 @import，强行使用会破坏作用域隔离和热更新逻辑。

什么情况下还能用 @import

仅限两个真实可行的场景，且需明确知道代价：

• 在已通过 加载的基础 CSS 文件内部，做条件化引入（如 @import url("print.css") print;），此时不影响屏幕样式加载
• 开发阶段临时调试，快速复用他人 CSS 片段（例如 @import url("https://cdn.example.com/reset.css");），但上线前必须转为 或内联合并

注意：@import 不支持 as 别名、type 类型提示、crossorigin 属性等现代 支持的控制能力，扩展性天然受限。

/* ❌ 不推荐：嵌套、阻塞、不可控 */ @import url("base.css"); @import url("theme.css") (prefers-color-scheme: dark); 
/ ✅ 推荐：HTML 中显式声明，支持预加载和媒体查询 /  

实际项目里，只要构建流程可控，就该把所有 @import 拆出来，改用 + 构建时合并或按需加载。真正难处理的，往往是第三方 ui 库自带的 @import 链，这时候得靠 postcss 插件（如 postcss-import）提前展开，而不是放任它跑在浏览器里。