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，它就足以打断整个关键渲染路径的并行能力

真正容易被忽略的点是：它的代价不是“慢一点”，而是引入了一个浏览器机制决定的硬性串行依赖——只要存在，就必然拖慢首屏，且无法靠 HTTP/2、preload 或构建优化绕过。