@import 会显著拖慢 css 解析，因其串行阻塞加载，易引发瀑布流；而 并行非阻塞，应将所有 @import 替换为按依赖顺序排列的 标签，并注意媒体查询、兼容性和构建工具适配。
为什么 @import 会让 CSS 解析变慢
浏览器解析 @import 是串行阻塞的：遇到一个 @import，必须先下载、解析完它引入的 CSS，才能继续后续样式表的加载和解析。哪怕只是写在 main.css 开头的一行 @import url("reset.css");，也会让整个页面的 CSS 构建完成时间往后拖。
而 <link rel="stylesheet"> 是并行非阻塞的（现代浏览器下），多个 <link> 可以同时发起请求，且不会中断主样式表的解析流程。
-
@import在 CSS 文件里使用时，还可能触发“CSS 加载瀑布流”——比如 A.css@importB.css，B.css 又@importC.css，实际变成 A → B → C 的链式加载 - 如果
@import写在<style></style>标签内（而非外部文件），它会等 HTML 解析到该标签才开始加载，进一步延迟样式就绪时机 - 某些旧版 Safari 对嵌套
@import的并发数限制更严，容易卡住首屏渲染
怎么把 @import 全换成 <link>
核心原则：把所有 CSS 文件的依赖关系，从“运行时导入”提前到“构建时/声明时组织”。不是简单替换语法，而是重构资源加载路径。
- 检查所有 CSS 文件，用文本搜索
@import，特别注意带引号/括号的变体：@import "foo.css";、@import url(bar.css);、@import 'baz.css' screen; - 把每个被
@import的文件，改成独立的<link>标签，按依赖顺序插入 HTML 的中（例如 reset.css 必须在 main.css 之前） - 如果项目用了构建工具（Webpack/Vite），直接删掉源 CSS 中的
@import，改用 JS 侧import "./reset.css"—— 工具会自动提取并生成<link> - 注意媒体查询不能直接挪到
<link>外部；@import url(x.css) print;要改成<link rel="stylesheet" href="x.css" media="print">
替换后要注意的兼容性细节
表面看只是换了个写法，但浏览器对 <link> 和 @import 的处理逻辑差异，会影响实际行为。
立即学习“前端免费学习笔记（深入）”；
-
<link>支持media、disabled、onload等属性，@import完全不支持动态控制，这点在需要条件加载时很关键 - CSS 优先级规则不变：多个
<link>按 HTML 中出现顺序叠加，和原来@import在文件中的位置逻辑一致 - HTTP/2 下多个
<link>并发优势更明显；但 HTTP/1.1 下过多小 CSS 文件反而增加连接开销，建议合并基础层（如 reset + base）为一个文件 - 某些老版本 IE（IE8 及以下）对
<link>的media属性识别有 bug，若需兼容，避免用media="not all"这类写法
怎么验证改得对不对
别只看页面显示是否正常，重点看网络和渲染时序是否真的改善了。
- 打开 Chrome DevTools → Network 面板，筛选
css，观察各 CSS 文件的 “Start Time” 和 “End Time”：理想情况是多个<link>几乎同时发起请求，而不是排成一列 - 切换到 Performance 面板，录制页面加载，展开 “Timings” → “Stylesheets”，看 “Parse Stylesheet” 阶段是否缩短，且没有长等待的 “Recalculate Style” 尖峰
- 用
document.styleSheets.length检查 JS 中读取的样式表数量是否符合预期（@import的文件不会出现在这里，而<link>会） - 如果用了 CSS-in-JS 或 Shadow DOM，确认
@import替换后不影响 scoped 样式隔离逻辑——它们内部的@import通常无法直接替换成<link>，得走对应框架的加载机制
真正卡顿的往往不是单个 @import，而是它引发的隐式依赖链和加载时序错乱。改完之后记得清空浏览器缓存再测，否则可能还在用旧的缓存版本做判断。
