多层嵌套@import会串行阻塞CSSOM构建，因浏览器必须暂停当前解析、等前一个@import下载并解析完才发起下一个请求，形成“A等B、B等C”链式等待，导致DOMContentLoaded延迟200–600ms且无法被preload或media控制。
为什么多层嵌套@import会串行阻塞CSSOM构建
因为浏览器解析 CSS 时，遇到 @import 必须暂停当前样式表的解析，发起新请求，并等它完整下载、解析完毕后，才能继续处理后续规则——这个过程无法并发，也不受预加载器（preload scanner）干预。两层嵌套（如 main.css → theme.css → utils.css）就会形成「A 等 B，B 等 C」的链式等待。
常见错误现象包括：
- Network 面板中多个 CSS 请求按 Start Time 排成一条竖线，Initiator 列全为
stylesheet -
DOMContentLoaded时间比平铺<link>高出 200–600ms（弱网下更明显） - Coverage 面板显示大量 CSS 规则“未使用”，但它们已因加载太晚而错过渲染时机
为什么@import无法被preload或media条件控制
@import 的 media 参数（如 @import url("dark.css") (prefers-color-scheme: dark)）只决定规则是否“生效”，不决定是否“下载”。浏览器仍会在页面初始化阶段强制拉取该文件，哪怕用户根本用不到它。
而 <link rel="stylesheet" href="dark.css" media="(prefers-color-scheme: dark)"> 才真正实现物理隔离：不匹配就不发请求。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：
- 误以为
@import url("print.css") print是懒加载——实际首屏就下，且阻塞渲染 - 在响应式项目里用
@import加载断点专属样式，结果所有断点 CSS 全被提前加载 - 把
media="(min-width: 0)"错用在@import上，它完全无效
Vite/Webpack 里看到 @import 不代表运行时有问题
现代构建工具默认用 postcss-import 在打包阶段展开 @import，只要配置正确，最终产出的 dist/main.css 里不应再出现明文 @import。
判断是否真有隐患，直接打开 dist 目录下的 CSS 文件检查：
- 如果里面还写着
@import url("vars.css")，说明构建配置漏掉了postcss-import或它没放在插件链首位 - Webpack 需确保
css-loader的importLoaders≥ 1，且postcss-loader启用了postcss-import - Vite 默认启用，但路径必须是相对路径或合法别名（如
@/styles/vars.css），不能拼接变量
替换嵌套@import的三个实操路径
不是简单删掉 @import 就完事，关键看资源声明位置和加载意图：
- 基础样式（重置、变量、工具类）→ 提前用
<link rel="stylesheet">同步加载 - 非关键模块（弹窗、评论、后台管理页）→ 拆成独立 CSS chunk，用
<link rel="preload" as="style" onload="this.rel='stylesheet'"> - 条件资源（暗色主题、打印样式）→ 改用
<link media="(prefers-color-scheme: dark)">，靠浏览器原生机制控制加载时机
最易被忽略的一点：即使你用 postcss-import 把所有 @import 展开成一个大文件，它仍是阻塞渲染的单一资源——真正的优化要落到「哪些规则必须首屏内联」「哪些可以异步加载」上，而不是只做语法扁平化。
