嵌套@import会卡住首屏渲染，因为浏览器必须等前一个css文件下载完成、解析并读到@import行后才发起下一个请求，形成硬性阻塞瀑布链，导致cssom构建和渲染树生成被死锁。
为什么嵌套 @import 会卡住首屏渲染
因为浏览器必须等前一个 CSS 文件下载完成、开始解析、读到 @import 那一行，才会发起下一个请求——它不是“慢一点”，是硬性阻塞。你看到的不是延迟，而是瀑布链：@import url("a.css") → 下载 a.css → 解析 a.css → 读到 @import "b.css" → 才发起 b.css 请求。
这个过程完全逃不过 HTML 预加载扫描器，<link> 能在解析 HTML 第一行就并发拉资源，@import 连“被看见”都要排队。CSSOM 必须等所有嵌套内容就绪才能构建，而渲染树被死锁在这一步——白屏时间直接受控于最深那一层的网络延迟。
如何把 @import 全部替换成
不能只删掉 @import 语句，必须重构依赖顺序和声明位置：
- 用文本搜索定位全部写法：
@import "reset.css"、@import url(utils.css)、@import 'theme.css' (prefers-color-scheme: dark) - 把每个被导入的文件（如
reset.css、utils.css）保留为独立文件，不再由其他 CSS 引用 - 在 HTML 的
中按依赖顺序插入<link rel="stylesheet">，媒体查询平移进media属性，例如：@import url(print.css) print→<link rel="stylesheet" href="print.css" media="print"> - 关键样式（如重置、布局、首屏组件）必须用无
media的<link>，且放在靠前位置
别被构建工具里的 “@import” 混淆了
SCSS/Less 的 @import 是构建时行为，和原生 CSS 的 @import 完全不同——但名字一样，上线前审查 Network 面板时极易误判“没用 @import”。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
Webpack 场景下，若同时启用了 css-loader 和 postcss-import，默认会冲突；Vite 默认不处理原生 CSS 中的 @import，它照常发运行时请求。
真正危险的是：你在 SCSS 里写了 @import "base/vars"，以为安全，结果上线后发现某个 main.css 里还藏着一行 @import url("legacy-theme.css") ——这行才是真正在拖慢首屏的那一个。
为什么 @import 在 IE 和现代工具链里都不可靠
旧版 IE（IE6–IE8）对 @import 有隐性限制：
-
@import必须位于 CSS 文件最顶部，前面不能有任何字符（包括 BOM、注释、空行），否则整个规则失效 - 媒体查询条件写在
@import后（如@import url(x.css) screen and (min-width:768px)）会被 IE6/7 完全忽略
CSS-in-JS 或模块化方案（如 CSS Modules）基本不支持 @import，强行使用会破坏作用域隔离和热更新逻辑；它也不支持 as 别名、type 类型提示、crossorigin 属性等现代 <link> 支持的能力。
@import 就该立刻停手——它不是“不够好”，而是把关键渲染路径直接焊死在瀑布链上。真正容易被忽略的，是那些藏在第三方库 CSS 文件里、没人 review 的 @import，它们不会报错，但会在弱网下悄悄把 LCP 推过 2s。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
