@import 会阻塞 CSS 解析并导致串行加载，嵌套越深首屏延迟越明显，2层以上常使 DOMContentLoaded 增加 200ms+，且无法被 preload 或 media 条件控制。
@import 会阻塞后续 CSS 解析，嵌套越深，首屏渲染延迟越明显
浏览器遇到 @import 时必须暂停当前样式表的解析，发起新请求并等它下载、解析完成，才能继续。如果这个被导入的 CSS 里又写了 @import，就会形成链式等待——不是并发加载，而是串行阻塞。
- 实际场景中，
@import嵌套 2 层以上，DOMContentLoaded时间常增加 200ms+（尤其弱网） -
@import在<style></style>标签内或外部 CSS 文件中效果一致，都会触发阻塞 - 和
<link rel="stylesheet">不同，@import无法被 preload 提前触发，也无法设置media类型做条件加载（除非写在支持该语法的顶层 CSS 中）
Chrome DevTools 里怎么确认 @import 是否造成加载瀑布流
打开 Network 面板，筛选 css，按 “Start Time” 排序，观察请求是否呈现明显的“一条接一条”纵向排列；再切换到 “Coverage” 面板，勾选 “Show unused CSS”，你会发现很多被 @import 拉进来的规则实际从未应用——因为它们加载太晚，页面已渲染完毕。
- 关键指标看
blocking time和wait time：若某 CSS 请求的 wait time 明显长于其他资源，大概率是被前一个@import卡住 - 右键点击该请求 → “Replay XHR” 无效，因为
@import是解析时行为，不是可重发的网络动作 - 禁用 JS 后刷新，仍能复现延迟，说明问题纯属 CSS 加载机制导致，和 JS 执行无关
替换 @import 的三种可行方式及兼容性取舍
没有“完美替代”，只有按场景选最不伤性能的方案。现代项目优先用构建工具处理，老系统需考虑 IE 支持。
- 用
<link rel="stylesheet">并行加载：HTML 中直接写多个<link>，浏览器会并发请求，但需手动维护顺序（依赖关系靠 HTML 位置保证） - Webpack/Vite 等打包时用
css-loader或postcss-import：把@import在构建期展开为内联 CSS，彻底消除运行时阻塞——但注意，postcss-import默认不处理嵌套@import中的url()路径，可能报Cannot resolve "./xxx.png" - 仅对 IE11 及以下保留
@import：放在<style></style>标签底部，并确保无嵌套；其他浏览器一律改用<link>或构建时展开
递归 import 不会爆栈，但会显著拖慢 CSSOM 构建
JS 引擎有调用栈限制，CSS 解析器没有栈溢出概念，所以 5 层 @import 不会报错，只会让浏览器花更久把所有规则合并进 CSSOM 树。这个过程不可见、不可打断，且期间 layout 触发会反复重排。
立即学习“前端免费学习笔记（深入）”；
- Chrome 90+ 对深度
@import做了轻微优化（缓存部分解析结果），但改善有限，实测 4 层嵌套仍比平铺<link>慢 30%+（以 LCP 为指标） - 不要指望
media="print"或media="(min-width: 992px)"让嵌套@import“懒加载”：只要解析到这行，请求就立即发出，媒体查询只控制是否应用规则，不控制是否下载 - 构建工具里如果用了
postcss-import+postcss-url，注意后者默认不重写嵌套文件里的url()，容易导致 404——得配url: { extensions: [".png", ".jpg"] }
