CSS中@import引入方式会引发哪些性能瓶颈？
@import会打断关键渲染路径，因为它是同步阻塞指令，强制暂停CSS解析等待导入资源下载完成，且预加载器无法发现它，导致请求延迟、LCP和DOMContentLoaded显著延长。
为什么@import会打断关键渲染路径
它不是资源声明，而是同步阻塞指令。浏览器在解析 CSS 时遇到 @import，必须暂停当前样式表的解析，等被导入的 CSS 下载、解析完成，才能继续——哪怕它写在 main.css 最末尾，也一样卡住整个 CSSOM 构建流程。
更关键的是：HTML 解析器根本“看不见”它。预加载器（preload scanner）只扫描 HTML 中的 <link>，对 CSS 文件里的 @import 完全无视。这意味着 reset.css 的请求，要等到 main.css 全部下载完、开始解析后才发出，白白浪费几百毫秒。
- 实测两层嵌套在弱网下可让 LCP 延迟增加 400–800ms
-
DOMContentLoaded时间常因此多出 200ms+，尤其在 HTTP/1.1 环境下 - Network 面板里请求 Initiator 显示为
stylesheet，而非parser，就是典型信号
@import无法配合media实现真正懒加载
@import url("print.css") print; 这类写法看似按条件加载，实际浏览器仍会在页面初始化阶段无差别下载该文件——它只跳过规则应用，不跳过请求本身。带媒体查询的 @import 对首屏性能毫无帮助，还占带宽、挤占连接数。
而 <link href="print.css" media="print"> 是真正的惰性加载：浏览器识别到非匹配媒体类型，直接跳过下载，完全不参与渲染阻塞。
立即学习“前端免费学习笔记（深入）”；
- 支持懒加载的
media值包括：print、(prefers-color-scheme: dark)、(min-width: 768px) -
@import后的媒体查询只控制规则是否生效，不影响资源获取时机 - 千万别写
@import (max-width: 768px) { ... }——语法非法，CSS 规范不支持
构建产物里残留@import暴露源码且增加请求数
Webpack/Vite 默认会对 Sass/Less 的 @import 做编译期合并，但原生 CSS 的 @import 是运行时行为，会被透传到打包产物中。一旦 dist 目录下的 main.css 里还留着 @import url("node_modules/xxx/index.css");，就等于把开发路径直接暴露给用户，还额外触发一次 HTTP 请求。
- 常见配置疏漏：
sass-loader关了api: 'modern'，导致降级为原生@import - Vite 项目中
css.preprocessorOptions.sass未启用 import 处理逻辑 - PostCSS 若没配
postcss-import或skipDuplicates: false，也会漏掉合并
JS动态插入@import完全无效
有人想用 JS 模拟按需加载，写 style.textContent = '@import url(theme.css)';，结果静默失败。因为 @import 必须出现在 CSS 文件或 <style> 标签最顶部，且仅在初始 HTML 解析阶段生效；运行时注入的字符串不会被重新解析，浏览器直接忽略。
真要动态加载主题或模块样式，只能操作 <link> 元素：document.createElement('link') + appendChild()，并监听 onload 控制后续行为。
-
@import不是 JS 可控的 API，它没有返回 Promise，也无法 abort 或 retry - 试图用 JS “补救”
@import的延迟，反而增加 JS 执行负担，得不偿失 - 哪怕只在单个 CSS 文件里用了一次
@import，它就足以打断整个关键渲染路径的并行能力
