本质上，@import 这种 CSS 加载机制天然构成串行加载链：浏览器必须等待前一个 CSS 文件完全下载并解析完毕后，才能发起下一个文件的请求。这正是 FOUC（无样式内容闪烁）最常见的根因之一。
关键在于，CSS 解析器虽然能够识别 @import 指令，但 HTML 预加载器（Preloader）却完全无法感知它的存在。这意味着浏览器无法提前发现这些样式资源，更无法实现并行下载，自然也就无从谈起任何优化策略。一旦出现多层嵌套——例如 A.css 中 @import 了 B.css，而 B.css 又 @import 了 C.css——加载延迟会级联放大，在慢速网络环境下额外增加 500ms 以上十分常见。更糟糕的是，IE 及旧版 Safari 的加载时机尤其极端：它们必须等到整个 DOM 解析完成后才开始读取 @import 规则，此时 HTML 早已渲染完毕，样式却姗姗来迟，FOUC 几乎必然出现。
从更深层次来看，现代前端构建工具（如 Vite、Webpack）的 preload 插件、CDN 预热逻辑、HTTP/2 多路复用等——这些针对 标签的优化手段，一旦遇到 @import 就会全部失效。因为 @import 并非解析器主动发现的资源，优化引擎根本不会将其视为需要预加载的对象。
将 @import 替换为
不一定。仅仅替换路径而不妥善处理依赖顺序，反而可能引发新问题：
- 重置类样式（如
reset.css、normalize.css）必须放在最前面的中，否则后续样式可能被浏览器默认样式覆盖，导致重置效果失效。 - 基础布局样式（如
grid.css、typography.css）应早于组件样式（如button.css、card.css）加载，否则组件的定位与间距可能因缺少基础规则而错乱。 - 非首屏样式（如
print.css）必须添加media="print"属性，否则它们会阻塞渲染，拖慢首屏加载时间。 - 所有
href路径必须确保可访问——只要其中一个返回 404，后续所有的 CSSOM 构建都会被中断，FOUC 依然会出现。
因此，仅替换 @import 远远不够，还需理清依赖顺序、正确设置条件加载，才能真正消除 FOUC。
如何在 DevTools 中快速定位 @import 引起的问题？
不要只检查 HTML 中是否包含 标签，关键在于观察网络请求链路：
- 打开 Network 面板，Filter 中输入
css，关注每个 CSS 请求的 Initiator 列：若显示parser，说明该资源被 HTML 解析器识别；若显示stylesheet或空白，则很可能是通过@import加载的。 - 右键点击任意 CSS 请求，选择 “Open in Sources”，搜索
@import，确认它是否隐藏在 SCSS / Less 的编译产物中——许多转译工具会悄悄输出@import，开发者自己都未必察觉。 - 临时将所有
media属性改为media="all"，刷新页面。若 FOUC 消失，说明原先的media条件不匹配当前环境，导致样式被异步加载。 - 检查响应头：
Content-Type必须为text/css，否则浏览器会拒绝解析并降级为非阻塞加载——此时样式自然延迟到达。
坦白说，即使将全部 @import 替换为 ，FOUC 仍有可能存在。因为主 CSS 文件如果体积过大（例如超过 200KB）、CDN 缓存未命中、或服务端采用了错误的压缩策略，同样会延迟样式就绪。只能说 @import 是最典型的诱因，但绝非唯一的变量——排查时务必保持全局视角。
