@import会拖慢首屏渲染，因为它强制串行加载：浏览器必须完整下载并解析主CSS后才能发现并请求@import资源，无法被HTML预加载器识别，导致瀑布链式请求，实测FCP延迟300–800ms；而<link>支持并行下载与早期资源发现。
为什么@import会拖慢首屏渲染
@import不是“慢一点”，而是硬性阻塞：浏览器必须等主 CSS 文件下载完成、开始解析、读到@import那行，才发起下一个请求。HTML 预加载器完全看不见它，<link>在解析 HTML 第一行就并发拉资源，@import连“被发现”都要排队。
常见错误现象包括：Network 面板看到明显的瀑布链（a.css → b.css → c.css），首屏白屏时间比等价的<link>多出 300–800ms；弱网或 CDN 缓存未命中时，延迟更剧烈。
- 嵌套两层
@import，相当于强制串行三次网络往返 - 即使被导入文件很小（如
reset.css），也要等前面文件整个传输+解析完才能启动下载 - HTTP/2 虽支持多路复用，但
@import仍无法提前预加载——顺序执行是语法层面的限制
构建工具和现代工程化里容易踩的坑
SCSS/Less 的@import和原生 CSS 的@import完全不是一回事：前者是编译期合并，后者是运行时请求。名字相同，但上线后行为天差地别。
你可能在 SCSS 里写了@import "vars"觉得安全，结果某个被输出的main.css里还藏着一行@import url("legacy-theme.css")——这行才是真正在拖慢首屏的罪魁祸首。
立即学习“前端免费学习笔记（深入）”；
- Webpack 同时启用
css-loader和postcss-import时，默认行为可能冲突 - Vite 默认不处理原生 CSS 中的
@import，它照常发运行时请求，不会自动内联或警告 - CSS-in-JS 或 CSS Modules 基本不支持
@import，强行使用会破坏作用域隔离
@import在IE和媒体查询中的隐性失效风险
旧版 IE（IE6–IE8）对@import有苛刻限制：必须位于 CSS 文件最顶部，前面不能有任何字符——包括 BOM、注释、空行，否则整条规则静默失效。
媒体查询写法看似合理，实则危险：@import url("print.css") print;在 IE6/7 中会被完全忽略；而@import url("x.css") screen and (min-width:768px);这种条件写法，在多数旧浏览器里也不生效。
-
@import不支持crossorigin、as、type等<link>具备的现代控制能力 - 动态插入
<style>并写入@import，等于主动绕过浏览器预加载器 - 即使只用于打印样式，浏览器仍会在初始解析时下载该文件（除非
@import被包裹在不匹配的@media块内，但兼容性极差）
替换方案不是简单删掉@import，而是重构依赖链
不能只把@import url("a.css")删掉，然后把a.css内容复制进去——那样会破坏模块边界、影响缓存复用、让热更新失效。关键是要把依赖关系显式暴露给构建系统或 HTML。
- 用文本搜索定位所有写法：
@import "reset.css"、@import url(utils.css)、@import 'theme.css' (prefers-color-scheme: dark) - 把每个被导入文件保留为独立资源，在 HTML 的
<head>中按依赖顺序插入<link rel="stylesheet"> - 媒体查询平移进
media属性：@import url(print.css) print;→<link rel="stylesheet" href="print.css" media="print"> - 关键样式（重置、布局、首屏组件）必须用无
media的<link>，且放在靠前位置
真正难的不是改代码，而是识别哪些@import是构建产物残留、哪些藏在第三方 CSS 包里、哪些被工具链自动注入——这些地方最容易漏查，也最常导致上线后性能回退。
