@import 是同步且阻塞的，会串行加载、暂停后续样式解析与渲染；应改用 、media="print" 切换或动态插入 实现真正异步加载。
@import 本身不是异步的，它会阻塞后续样式的解析和渲染，用它“提高加载速度”反而适得其反。
为什么 @import 实际上是同步且阻塞的
CSS 中的 @import 规则在解析时会触发同步网络请求，并暂停当前样式表的后续处理，直到被导入的资源加载并解析完成。浏览器不会并行下载多个 @import 链，而是串行执行——比如 A.css 里 @import "B.css"，B.css 里又 @import "C.css"，就会形成 A → B → C 的瀑布链。
- 即使写在
<style></style>标签末尾，也不能绕过这个阻塞行为 - 在
<link rel="stylesheet">之后使用@import，仍会阻塞该<style></style>块之后的 CSS 和页面渲染 - Chrome DevTools 的 Network 面板中能看到明显的请求延迟叠加
真正能异步加载样式的替代方案
想实现“异步加载 CSS 并避免阻塞”，应该放弃 @import，改用以下方式：
- 用
<link rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'" href="async.css">：预加载 + 动态切换 rel，实现无阻塞加载 - 配合
media="print"属性临时隐藏加载影响：<link rel="stylesheet" href="async.css" media="print" onload="this.media='all'"> - JavaScript 动态创建
<link>（注意避免 FOUC）：在 DOMContentLoaded 后插入，或配合media="none"+ onload 切换
这些方法都依赖 <link>，而非 @import；@import 没有 onload 事件、无法动态控制、也不支持 preload。
立即学习“前端免费学习笔记（深入）”；
哪些场景还在误用 @import？
常见但有问题的用法包括：
- 在 Sass/Less 中习惯性写
@import "reset"—— 这是预处理器指令，编译后消失，不等于 CSS 的@import，但开发者常混淆二者行为 - 为“组织代码”在生产环境 CSS 文件里保留
@import，结果引入了隐蔽的性能瓶颈 - 试图用
@import url("a.css") screen and (min-width:768px)实现媒体查询加载——实际仍是同步请求，只是应用条件不同
预处理器的 @import 和 CSS 原生 @import 是两套机制，不能互相替代或类比。
如果必须用 @import，至少避开这些坑
极少数遗留系统或内联 <style></style> 场景下无法移除 @import，可做最小化补救：
- 确保所有
@import都写在样式表最开头（CSS 规范要求），否则会直接被忽略 - 避免嵌套：一个
@import链深度不要超过 1 层 - 绝对不要在
<style></style>标签中混用@import和普通规则（如body { ... }），否则@import后的规则全部失效 - 用
curl -I或浏览器 Network 面板确认被 import 的文件返回的是text/cssMIME 类型，否则可能静默失败
真正关键的点在于：异步加载不是靠语法糖实现的，而是靠资源加载时机与渲染流程的解耦——@import 天然不具备这个能力，强行用它“优化”，只会让问题更隐蔽。
