@import 会阻塞后续 CSS 和 JS 执行，因其强制同步加载、暂停解析并串行请求，导致白屏延长、JS 卡顿；应全部替换为 标签实现并行下载与异步解析。
@import 会阻塞后续 CSS 和 JS 的执行
用 @import 在 CSS 文件里引入其他样式表，浏览器会把它当成「同步加载、必须等它下载解析完才能继续」的任务。这不是懒加载，是硬性阻塞——哪怕你把 @import 写在文件末尾，它依然会让整个 CSS 解析暂停，连带阻塞后续 <script></script> 的执行（尤其是内联脚本或没有 async/defer 的外部脚本）。
常见错误现象：
– 页面白屏时间变长，尤其首屏关键 CSS 里用了 @import
– Chrome DevTools 的 Network 面板显示 CSS 文件请求明显串行，且后续 JS 请求被卡住
– Lighthouse 报「Render-blocking resources」，但你没意识到问题出在 @import 上
- 使用场景：老项目迁移、CSS 预处理器（如 Sass）的
@import语法容易让人误以为和原生 CSS 行为一致，其实编译后若输出为原生@import，就踩坑了 - 参数差异：原生 CSS 的
@import url("a.css")不支持媒体查询条件以外的任何逻辑；而 Sass 的@import "a"是编译时合并，不产生 HTTP 请求——但一旦编译配置出错或混用，就可能漏掉转换 - 性能影响：每个
@import都新增一个 HTTP 请求（HTTP/1.1 下无法复用连接），且无法与主 CSS 并行解析；HTTP/2 虽能多路复用，但仍无法并行解析，因为规范强制要求顺序处理
替代方案：link 标签 + 条件加载更可控
把 @import 全部换成 <link rel="stylesheet">，浏览器就能并行下载、异步解析，JS 也不会被无故卡住。
实操建议：
– 把原本写在 main.css 里的 @import url("vendor.css"); 拆出来，直接在 HTML 的 里加一行：<link rel="stylesheet" href="vendor.css">
– 如果要按媒体类型加载（比如 print 样式），用 media 属性比 @import 更轻量：<link rel="stylesheet" href="print.css" media="print">，这样它默认不阻塞屏幕渲染
立即学习“前端免费学习笔记（深入）”；
- 兼容性没问题：所有现代浏览器对
<link>的并行加载支持远好于@import - 构建工具注意：Webpack/Vite 等打包 CSS 时，若源码用了 Sass/Less 的
@import，确保 loader 配置正确（如sass-loader默认已处理，但若关了api: 'modern'可能退化） - 不要用 JS 动态插入
<link>来“模拟”@import的延迟加载——这反而增加 JS 执行负担，且失去预加载器（preload scanner）的优化
HTTP/2 和 preload 不能挽救 @import 的设计缺陷
有人觉得上了 HTTP/2 就不用怕 @import 的请求串行，这是误解。HTTP/2 解决的是 TCP 连接复用，不是解析顺序。浏览器仍必须按 CSS 字节流顺序执行 @import，遇到它就得停住、发请求、等响应、再继续解析——这个过程无法跳过或重排。
即使加上 <link rel="preload" as="style" href="a.css">，也只是提前触发下载，但解析时机仍由 @import 语句位置决定，preload 不会改变 CSS 解析器的行为。
- 真实调试技巧：在 Chrome DevTools 的 Rendering → Paint Flashing 开启后，如果看到某块区域迟迟不渲染，配合 Network 面板过滤
css，看是否有请求明显晚于其他资源发起，大概率就是@import在作祟 - CI 检查项：可用 PostCSS 插件（如
postcss-import-nope）在构建时扫描源 CSS 文件，报出所有原生@import语句，避免漏改 - 注意 CSS-in-JS 库（如 Emotion）内部若封装了类似逻辑，也要确认它是否生成了原生
@import—— 大部分现代库已规避，但定制主题方案时可能绕过
真正麻烦的不是发现 @import，而是它常藏在第三方 CSS 包里，或者被构建工具“静默保留”。上线前用 DevTools 的 Coverage 工具扫一遍 CSS 文件，看看哪些规则实际没用到，顺便检查有没有可疑的 @import 行——人眼比工具更容易忽略那一行小字。
