CSS @import 引入方式会带来哪些性能瓶颈？
来源：互联网 2026-07-19 08:18:14CSS中的@import是同步阻塞指令，会暂停当前样式表解析，等待被导入文件下载完成才能继续，导致预加载器无法提前发现资源请求，首屏耗时增加。实测其可让LCP延迟增加400-800毫秒，无法实现真正懒加载，且构建产物中残留的@import会额外触发HTTP请求，JS动态注入同样无效。
@import，许多开发者的第一印象是“方便”——将第三方样式直接插入主文件，似乎就能解决问题。但性能代价往往隐藏在表面之下。严格来说，@import 并非简单的资源引入，而是一条同步阻塞指令：浏览器在解析 CSS 时遇到它，必须暂停当前样式表的解析，等待被导入的文件下载并解析完成后，才能继续执行——即便它写在 main.css 最末尾，整个 CSSOM 构建流程也会被卡住。更致命的是，HTML 解析器根本无法“看见”它。预加载器（preload scanner）只扫描 HTML 中的 @import 完全无视。这意味着 reset.css 的请求要等到 main.css 全部下载完成并开始解析后才会发出，白白浪费几百毫秒。
为什么@import会打断关键渲染路径
它不是资源声明，而是同步阻塞指令。浏览器在解析 CSS 时遇到 @import，必须暂停当前样式表的解析，等待被导入的 CSS 下载、解析完成，才能继续——哪怕它写在 main.css 最末尾，也一样卡住整个 CSSOM 构建流程。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
更关键的是：HTML 解析器根本“看不见”它。预加载器（preload scanner）只扫描 HTML 中的 ，对 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 对首屏性能毫无帮助，还占带宽、挤占连接数。
而 是真正的惰性加载：浏览器识别到非匹配媒体类型，直接跳过下载，完全不参与渲染阻塞。
- 支持懒加载的
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 文件或