@import让首屏渲染变慢，因浏览器需等主CSS下载解析完才发起导入请求，导致串行加载、阻塞CSSOM构建；而可并行下载，HTTP/1.1下更显著，HTTP/2也无法绕过其解析顺序限制。
为什么@import会让首屏渲染变慢
因为浏览器必须等主 CSS 文件下载完成、开始解析，遇到 @import 那一行时，才发起被导入文件的请求。这打断了原本可并行下载的资源调度，把关键渲染路径拉长。
常见错误现象：main.css 里写了 @import url("reset.css")，结果 reset.css 要排队等 main.css 的网络传输 + 解析完成才能启动下载；而用 <link> 时，两个文件能同时发起请求。
HTTP/1.1 下尤其明显：单域名并发连接数通常只有 6 个，@import 还会额外占一个“隐式连接槽”；HTTP/2 虽支持多路复用，但 @import 仍需按语法顺序解析，无法提前预加载。
为什么@import容易触发 FOUC
@import 的加载时机晚于 DOM 构建。尤其在弱网或 CSS 较大时，浏览器先渲染出无样式的 HTML 内容，等 @import 的 CSS 终于加载完才重绘——用户会看到「白屏→文字乱排→突然整齐」的闪烁。
这个现象在移动端更明显：首屏渲染快，但 @import 的 CSS 还卡在队列里。
多个 @import 嵌套（比如 A.css → @import B.css → @import C.css）会让 FOUC 概率倍增，且无法通过 JS 监听或控制加载状态。
为什么@import无法被 JavaScript 动态控制
@import 是 CSS 解析器在初始 parse 阶段识别的规则，运行时注入无效。
以下操作都不会生效：
-
style.textContent = '@import url("theme-dark.css")';—— 浏览器静默忽略 -
document.styleSheets列表里看不到它导入的样式表，只能递归访问cssRules，且时机不可靠 - 没法用
disabled = true临时禁用某份导入样式
而 <link> 是 DOM 元素，可直接用 document.createElement('link') 插入、监听 onload/onerror、切换 media 属性做响应式加载。
为什么构建工具和 CDN 容易被@import坑到
Webpack/Vite 等工具对 @import 的静态分析能力弱，容易漏掉依赖、重复打包、热更新失效，甚至导致 tree-shaking 失效。
CDN 缓存未命中时，@import 的串行链会暴露得更彻底：主 CSS 缓存命中，但子 CSS 因路径未被预热而走回源，延迟翻倍。
SCSS/Less 中的 @import 是编译期行为，和原生 CSS 的 @import 完全不是一回事——名字相同，语义和影响天差地别，极易混淆。
最常被忽略的一点：你在 <style></style> 标签里写 @import，看起来只是换种写法，其实已经把样式加载逻辑从 HTML 解析阶段，强行拖到了 CSS 解析阶段。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
