link性能更优，因其支持并行下载、避免FOUC、兼容动态插入；@import则强制串行加载、引发FOUC、不支持JS动态注入且易与构建工具及CDN冲突。
@import为什么比更容易引发FOUC
根本原因是加载机制不同：@import 在 CSS 文件内部使用时，会强制浏览器串行加载——必须等前一个样式表下载、解析完，才发起下一个 @import 的请求。而多个 <link rel="stylesheet"> 是并行发起的，网络层能充分利用连接复用和 HTTP/2 多路复用。
更糟的是，@import 还会阻塞后续 CSS 的解析：哪怕你写了 @import "a.css"; @import "b.css";，浏览器也不会提前预加载 b.css，必须等 a.css 完全就绪后才开始请求 b.css。这在慢网或 CDN 延迟高时，首屏关键样式就绪时间可能多出 300–800ms，直接触发 FOUC（Flash of Unstyled Content）。
- IE 和旧版 Safari 对
@import的处理尤其保守，甚至会延迟到 DOM 解析完成后再开始加载 -
@import无法被 HTML 解析器预加载，构建工具（如 Vite/Webpack）的 preload 插件也完全感知不到它 - 即使把
@import写在<style>标签里，它仍走 CSS 解析路径，不享受<link>的早期资源发现机制
如何安全替换页面中所有@import
不是简单地“删掉 @import 改成 <link>”，而是要按依赖顺序和渲染优先级重新组织外链结构。
比如原 CSS 中有：@import "reset.css"; @import "layout.css"; @import "components/button.css";，不能直接改成三个 <link> 并列扔进 <head> —— 这会破坏层叠顺序，导致 button.css 里的规则被 reset.css 覆盖。
立即学习“前端免费学习笔记（深入）”；
- 提取出所有
@import路径，按出现顺序整理为依赖链 - 将重置类（reset、normalize）、基础布局（grid、flex utilities）、主题变量（CSS custom properties）放在最前面的
<link> - 组件样式按实际使用顺序排列，确保父容器样式先于子组件加载
- 非首屏样式（如
print.css、dark.css）必须加media属性，避免参与首次渲染阻塞
构建阶段如何自动拦截@import
靠人眼检查 CSS 源码不可靠，尤其在多人协作或引入第三方 UI 库时。@import 很容易混进 SCSS/Less 编译产物里，最终输出到生产环境。
Vite 用户可启用 css.preprocessOptions + 自定义插件，在 transform 钩子中正则匹配 /@import\s+["']([^"']+)["']/g 并抛错；Webpack 则建议在 css-loader 配置中设 importLoaders: 0，并配合 eslint-plugin-css-modules 检查源文件。
- CI 流程中加入脚本：用
grep -r "@import" src/ --include="*.css"扫描纯 CSS 文件，命中即失败 - 若必须保留
@import（如某些设计系统文档站），至少确保它只出现在dev环境的 style 标签内，构建时被剔除 - 注意：Sass 的
@use和@forward不在此列，它们是编译期指令，不会生成运行时@import
为什么移除了@import还是有闪烁
常见错觉是“只要没 @import 就安全了”，但真正决定 FOUC 是否发生的，是**关键 CSS 是否在首次绘制前就绪**——哪怕全是 <link>，如果它们都指向一个体积大、CDN 延迟高、未开启 Brotli 压缩的 app.css，照样闪。
此时问题已不在语法层面，而在资源调度策略：
- 确认首屏必需样式是否已内联（
<style>标签，≤14KB），而非仅靠外链 - 检查
<link rel="preload" as="style">是否只针对提取出的critical.css，且带onload="this.rel='stylesheet'" - 用 Chrome DevTools 的 “Coverage” 面板验证，是否真有大量 CSS 规则在首屏渲染后才被用到
- 服务端渲染（SSR）场景下，
@import被移除后，仍需确保服务端动态注入的 critical CSS 与客户端 hydration 时的样式树一致，否则会二次 diff 导致样式跳变
