@import 会显著拖慢首屏渲染，因其强制串行加载：浏览器必须先下载并解析主 CSS 文件后才发起被导入文件请求，无法与 HTML 解析或其它资源并行，且不被预加载器识别。
为什么@import会让首屏渲染变慢
@import 是 CSS 语法级的导入，浏览器必须先下载、解析完主 CSS 文件，遇到 @import 行才发起被导入文件的请求。这打断了并行加载——比如 main.css 里写了 @import url("reset.css")，那 reset.css 就得排队等 main.css 的网络传输 + 解析完成，而用 <link rel="stylesheet" href="reset.css"> 时，两个文件能同时开始下载。
HTTP/1.1 下尤为明显：单域名并发连接数通常只有 6 个，@import 还会额外占一个“隐式连接槽”；HTTP/2 虽支持多路复用，但 @import 仍需按语法顺序解析，无法提前预加载。
为什么构建工具不帮你兜底
Webpack、Vite 等默认不处理纯 CSS 文件里的 @import，尤其当路径是相对路径或跨包引用时，很容易在生产环境 404。它们只对 JS 中的 import './styles.css' 做静态分析和依赖收集。
- JS 里写
if (process.env.NODE_ENV === 'development') { import('./dev-theme.css') }—— 构建工具无法静态识别，热更新失效、Tree-shaking 失效，甚至报错Dynamic require is not supported - 在
<style></style>标签里写@import—— 浏览器直接忽略（规范要求只能出现在样式表开头） - Sass/Less 的
@import是预处理器指令，编译期就合并，和原生@import完全不是一回事，名字相同但行为天差地别
为什么才是唯一靠谱的引入方式
<link rel="stylesheet"> 是 HTML 解析阶段触发的，浏览器预加载器（preload scanner）能立刻识别并发起请求，和 HTML 解析并行。它还支持：
立即学习“前端免费学习笔记（深入）”；
-
media属性做条件加载（如media="(prefers-color-scheme: dark)"） -
rel="preload"提前拉取关键样式 -
onload/onerror事件监听加载状态 - 多个
<link>按 HTML 中顺序执行，逻辑清晰、可预测
而 @import 在 CSS 解析阶段才触发，HTML 可能已解析过半， 内容都快出来了，才开始加载子样式表。
哪些“看起来没问题”的场景其实最危险
开发阶段本地服务器快、文件小、缓存足，@import 几乎没感知。但上线后：
- CDN 缓存未命中，串行瀑布效应立刻放大
- 弱网环境下，嵌套两层
@import实测可让首屏延迟增加 300–800ms - 媒体查询中写
@import url("print.css") print—— 浏览器仍会在初始解析时下载该文件（除非是@import在@media块内且规则不匹配，但兼容性差） - 动态插入
<style></style>并写入@import—— 不仅串行，还绕过了预加载器，等于放弃所有性能优化
真正要拆分样式，应该用构建时方案：PostCSS 的 postcss-import（编译期内联）、Sass 的 @use、或 JS 中静态 import 配合构建配置控制输出。运行时的 @import，生产环境没理由留它。
