@import会阻塞渲染，因其在CSS解析阶段才触发同步请求，浏览器必须等待导入文件下载解析完毕才能继续构建CSSOM和渲染；而link标签由HTML预加载器并行发起请求，不阻塞解析。
为什么@import会阻塞渲染，而合并文件只是治标不治本
@import 是 CSS 解析时才触发的同步请求，浏览器必须等它下载、解析完，才能继续处理当前样式表里后续规则，更别说构建 CSSOM 和渲染页面了。这和 HTML 中 <link rel="stylesheet"> 的预加载机制完全不同——后者在 HTML 解析第一行时就被预加载器发现，并发发起请求。@import 多一层解析延迟，还容易嵌套成瀑布链（比如 A.css → @import B.css → @import C.css），首屏白屏时间直接多出几百毫秒。
合并 CSS 文件真能解决 @import 的阻塞问题吗
不能。手动把多个 CSS 文件内容拼进一个文件，再用 @import 引入它，阻塞依然存在；而如果把所有样式直接写进主 CSS（即“物理合并”），确实消除了请求，但代价是：无法按需加载、缓存失效粒度变大、调试困难、source map 断链。更重要的是，现代项目中真正该合并的不是“所有 CSS”，而是首屏关键样式——非关键部分（如打印样式、暗色主题）应保留独立 <link> 并配 media 属性，由浏览器按条件跳过下载。
- 构建工具（如 Vite/Webpack）能自动内联或拆分，但前提是没在配置里禁用预处理，比如 Sass 用户误设
api: 'legacy'，Vite 用户漏配css.preprocessorOptions.sass - 检查最终上线的 CSS 文件里是否还有残留
@import：有，说明构建没生效，不是“合并了”，只是“看起来合并了” - HTTP/2 虽支持多路复用，但首次 TCP/TLS 握手仍需时间；过多
<link>仍可能拖慢首屏，建议首屏关键 CSS 控制在 ≤3 个请求内
什么时候该用 @import，什么时候必须换 link
几乎永远不该在生产环境的主样式表里用 @import。它唯一合理场景是：CSS 预处理器（Sass/Less）源码中的 @import，且确保构建阶段被完全展开为内联样式；或者极老项目中为兼容 IE 的 hack 写法。所有运行时动态引入需求（主题切换、模块样式懒加载）都必须用 JS 创建 <link> 标签，因为 @import 不支持 onload、不响应 media 匹配、也无法被 preload 提前拉取。
-
@import url("theme.css") screen and (prefers-color-scheme: dark)这种写法无效：媒体查询不阻止初始下载，浏览器照下不误 - 正确做法是
<link href="theme.css" media="(prefers-color-scheme: dark)">，匹配时才发起请求 - 想预加载？只能用
<link rel="preload" as="style" href="theme.css">+ onload 切换rel，@import没这个能力
构建产物里还看到 @import，说明什么
说明构建流程没接管 CSS 导入逻辑。常见原因包括：Sass 编译器降级到原生 CSS @import（比如 Webpack 的 sass-loader 配置了 implementation: require('sass') 但没开 modern API）、Vite 中 css.preprocessorOptions.sass 为空对象导致未启用预处理、或用了 mini-css-extract-plugin 却把样式打进了 JS chunk（此时 @import 会以字符串形式留在 JS 里，运行时由 JS 注入 style 标签，反而更慢）。
立即学习“前端免费学习笔记（深入）”；
最简单的验证方式：打开线上 CSS 文件，Ctrl+F 搜 @import。只要还有，就不是“已合并”，而是“构建失败”或“配置绕过”。这点容易被忽略，但直接影响首屏性能。
