@import 会阻塞 css 解析，因其串行加载机制要求浏览器必须下载并解析完被引入的 css 后才能继续处理后续规则，导致 cssom 构建延迟和渲染阻塞。
为什么 @import 会阻塞 CSS 解析
@import 不是并行加载，而是串行解析执行。浏览器遇到 @import 规则时，必须先下载、解析完被引入的 CSS 文件，才能继续处理后续样式规则——哪怕它写在文件末尾。
这和 <link rel="stylesheet"> 的行为完全不同：<link> 是异步发起请求，不阻塞后续 CSS 解析（现代浏览器下）。
- 每个
@import都会触发一次新的 HTTP 请求（即使多个@import指向同一域名） - 嵌套
@import（如 A.css 中@import "B.css"，B.css 中又@import "C.css"）会形成「瀑布链」，加载延迟逐层放大 - CSSOM 构建必须等所有
@import内容就绪，导致渲染阻塞时间延长
@import 在不同位置的表现差异
写在 CSS 文件顶部 vs 写在 @media 块内，影响完全不同：
- 顶层
@import（即不在任何条件块中）：**立即阻塞**，浏览器会暂停当前样式表解析，优先获取导入资源 - 位于
@media查询内的@import（如@import url("print.css") print;）：仅当媒体查询匹配时才加载，**不阻塞主样式流**，但依然有延迟 - 写在
@keyframes或@font-face后面？无效——@import必须出现在样式表最前面（除@charset外），否则会被忽略
替代方案：什么时候该用 <link>，什么时候不能避免 @import
绝大多数场景下，<link> 是更优选择；只有极少数情况需要保留 @import：
立即学习“前端免费学习笔记（深入）”；
- 需要根据 CSS 环境变量或媒体类型动态加载（如主题切换依赖
@media (prefers-color-scheme)） - 构建流程中已将多份 CSS 合并，但需保留源码级逻辑分组（此时
@import仅用于开发，构建后应被剔除） - 第三方 UI 库文档明确要求用
@import（例如某些旧版 Sass 输出，或 Web Component 封装限制）
注意：<link> 支持 preload、as="style" 和 onload 回调，而 @import 完全无法控制加载生命周期。
如何快速检测页面是否滥用 @import
打开 Chrome DevTools → Network 面板 → 过滤 css → 查看「Initiator」列：
file.css:123 → import.css import.css:45 → nested.css
如果看到多层冒号路径，说明存在嵌套 @import；再对比同页面中 <link> 请求的「Start Time」和「End Time」，通常能明显看出阻塞延迟。
另外，在 Elements 面板选中 <style></style> 或 <link> 节点，右侧 Styles 面板顶部若显示「@import rules are not shown」提示，也意味着该样式表里有未展开的导入链——这本身就是性能隐患信号。
真正麻烦的不是单个 @import，而是它藏在第三方 CSS 里，且没有 sourcemap 或文档说明。这种情况下，连定位都得靠抓包 + 二分注释。
