@import强制串行加载且不支持真正的媒体查询，会显著延迟CSSOM构建并浪费带宽；应改用<link>实现并行加载与条件加载，并校准路径、顺序及构建配置。
为什么@import强制串行加载，打断关键渲染路径
浏览器解析 CSS 时，@import 是同步、阻塞式语法：必须等当前 @import 的资源下载完成、解析完毕，才能继续处理后续样式规则。它不参与 HTML 解析器的早期资源发现，也不触发预加载器——只有 CSS 解析器执行到那一行，才发起网络请求。
对比 <link rel="stylesheet">：HTML 解析器一见到标签就并发发起请求，多个 <link> 可并行下载，且不卡主 CSS 解析流程。
- 实测中，单层
@import常让首屏 CSSOM 构建延迟 200–400ms；嵌套两层（如 A.css → B.css → C.css）在 HTTP/1.1 下瀑布延迟常超 600ms - 即使
@import url("reset.css");写在main.css开头，它也得排队等main.css完整下载+解析完才启动，而用<link>两者可同时请求 - Network 面板里 Initiator 显示为
stylesheet（而非parser），基本就是@import在链式触发
媒体查询在@import里根本不管用
@import 后面写的 media（比如 @import url("dark.css") (prefers-color-scheme: dark);）只是控制样式是否“生效”，不是控制资源是否“下载”。浏览器照常拉取该文件，哪怕用户压根不用暗色模式。
而 <link rel="stylesheet" href="dark.css" media="(prefers-color-scheme: dark)"> 中的 media 是真正的加载开关：现代浏览器识别后，根本不会发请求，直到系统切换或匹配条件触发。
立即学习“前端免费学习笔记（深入）”；
- 常见误用：
@import url("print.css") print;—— 打印样式仍会在首屏被下载，浪费带宽且延长白屏 - 非法写法：
@import不能放在@media块内部（如@media (max-width: 768px) { @import "mobile.css"; }），CSS 规范不支持，多数浏览器直接忽略 - 真正按需加载暗色主题或响应式断点，必须把
media移到<link>标签上
构建产物里残留@import = 生产环境埋雷
Webpack/Vite 项目里看到源码有 @import "./vars.css"; 不代表运行时有问题——如果启用了 postcss-import 或 css.extract，它大概率已被内联或拆成独立 <link>。但最终产出的 dist/ 目录下，若 main.css 文件里还明文写着 @import，说明构建流程漏处理了，必须修正配置。
- 第三方 UI 库打包后的 CSS 也可能藏
@import，且无 sourcemap，这类最难排查 - 残留的
@import会暴露开发期路径（如@import "../../node_modules/xxx/index.css";），可能泄露项目结构 - 某些 PostCSS 配置未设
skipDuplicates: false，会导致重复引入、体积膨胀
替换@import时最容易踩的坑
不是简单把 @import url("a.css"); 改成 <link href="a.css" rel="stylesheet"> 就完事。路径、顺序、媒体类型都要重校验。
-
@import的路径是相对于当前 CSS 文件位置，而<link>是相对于 HTML 页面——迁移时注意补全路径或改用绝对路径（如/css/a.css） - 多个
<link>的加载顺序由 HTML 中出现顺序决定，要严格对应原@import在 CSS 中的先后关系（例如reset.css必须在main.css之前） -
media="all"或空media属性在<link>中反而危险：部分浏览器会误判为非关键资源，导致样式失效 - HTTP/1.1 下过多小 CSS 文件会增加连接开销，建议合并基础层（如 reset + base）为一个文件，再搭配
<link>引入
@import 的串行机制和媒体查询形同虚设，是设计层面的硬伤。迁移到 <link> 看似只是换标签，但背后涉及路径语义、加载时机、构建配置三重校准，漏掉任何一点都可能白忙活。 
