嵌套 @import 会严重阻塞首屏渲染，因其运行时逐层阻塞加载、无法预加载、延迟指数级增长；应全部替换为按序声明的 <link> 标签，并注意构建工具中编译期与运行期 @import 的混淆问题。
嵌套超过一层的 @import 就该立刻停手——它不是“慢一点”，而是把关键渲染路径直接焊死在瀑布链上。
为什么嵌套 @import 会卡住首屏渲染
浏览器对 @import 的处理是纯运行时、无预加载、强依赖的：必须等前一个 CSS 文件下载完成 + 开始解析 + 读到 @import 那一行，才会发起下一个请求。这不是延迟，是硬性阻塞。
-
@import url("a.css")→ 下载 a.css → 解析 a.css → 读到@import "b.css"→ 才发起 b.css 请求 - 这个过程无法被 HTML 预加载扫描器发现，
<link>能在解析 HTML 第一行就并发拉资源，@import连“被看见”都要排队 - CSSOM（CSS 对象模型）必须等所有嵌套
@import内容就绪才能构建完成，而渲染树构建被死锁在这一步——白屏时间直接受控于最深那一层的网络延迟
实测影响有多严重
两层嵌套（A.css → B.css → C.css）在 3G 网络下可导致 FCP 延迟增加 300–800ms；四层以上时，LCP 经常突破 2s，用户已感知明显卡顿。
- 延迟不是线性增长，而是指数级：每多一层，就多一次 DNS 查询 + TCP 握手 + TLS 协商（尤其未启用 HTTP/2 时）
- DevTools 的 Network 面板里看不到“并行请求”，只有清晰的 A→B→C 瀑布流，且每个请求的 “Start Time” 明显错开
- 即使所有文件都在本地缓存，浏览器仍要按顺序解析 CSS 文本，逐层触发
@import，无法跳过
怎么改才真正有效
不能只删掉 @import 语句，必须重构资源声明位置和依赖顺序。
立即学习“前端免费学习笔记（深入）”；
- 用文本搜索定位全部写法：
@import "reset.css"、@import url(utils.css)、@import 'theme.css' (prefers-color-scheme: dark) - 把每个被导入的文件（如
reset.css、utils.css）保留为独立文件，不再由其他 CSS 引用 - 在 HTML 的
<head>中按依赖顺序插入<link rel="stylesheet">，媒体查询平移进media属性，例如：@import url(print.css) print→<link rel="stylesheet" href="print.css" media="print"> - 关键样式（如重置、布局、首屏组件）必须用无
media的<link>，且放在<head>靠前位置
构建工具里别被“编译期 @import”骗了
SCSS/Less 的 @import 是构建时行为，和原生 CSS 的 @import 完全不同——但名字一样，上线前审查 Network 面板时极易误判“没用 @import”。
- Webpack 场景下，若同时启用了
css-loader和postcss-import，默认会冲突：css-loader尝试发 HTTP 请求，postcss-import做文本替换，结果要么 404，要么样式重复注入 - 正确做法是关闭
css-loader的import功能：{ loader: 'css-loader', options: { import: false } }，并确保postcss-loader在css-loader之前执行 - Vite 用户虽默认启用
postcss-import，但若关了css.devSourcemap，展开后将无法定位原始 SCSS 行号——调试成本反而上升
真正难搞的从来不是你自己写的 @import，而是第三方 UI 库文档里明晃晃写着的 @import 示例。上线前不转成 <link> 或内联合并，性能瓶颈就埋在那里，等弱网用户帮你触发。
