详尽解析CSS @import 引入方式对页面性能的阻塞影响

说到 CSS 中的 @import，许多开发者的第一反应往往是“方便”——只需将第三方样式直接引入主文件，似乎就能轻松搞定。然而，这种便捷背后往往隐藏着不容忽视的性能代价。严格来说，@import 并非简单的资源引入指令，而是一条同步阻塞命令：浏览器在解析 CSS 时一旦遇到它，就必须暂停当前样式表的解析，等待被导入的文件下载并解析完毕，才能继续后续流程——即便它被写在 main.css 的最末尾，整个 CSSOM 构建过程依然会被卡住。更严重的是，HTML 解析器根本“看不到”它的存在。预加载器（preload scanner）仅扫描 HTML 中的 标签，而对 CSS 文件内部的 @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 文件或