@import不会被HTML预加载扫描器识别，必须等CSS文件下载解析后才触发请求，导致串行加载；而<link>在HTML解析阶段即被发现并可并行下载。
@import 不会被 HTML 解析器预扫描，它完全逃不出 CSS 解析阶段的串行控制。
浏览器在 HTML 解析时，只识别 <link rel="stylesheet">、<style> 和内联 style 属性——这三类资源能被预加载扫描器（preload scanner）提前发现并并发发起请求。@import 不在此列，它藏在 CSS 文件里，必须等该 CSS 文件下载完成、开始解析后才被“看见”，此时 HTML 解析早已推进一大截，甚至可能已开始渲染。
为什么 @import 在 HTML 解析阶段“隐身”
HTML 预加载扫描器是纯 HTML 词法分析器，不执行 CSS 解析逻辑。它只认标签和属性，不读 CSS 内容。@import 是 CSS 规则，不是 HTML 标签，所以：
- 即使写在 <style> 块开头，也要等整个 <style> 文本被 parser 收集完、交给 CSS 引擎后才处理
- 即使 @import 指向的是本地文件或 CDN 资源，也不会被提前触发下载
- 它无法享受 preload scanner 的并发红利，更无法被 rel="preload" 提前捕获
@import 实际触发时机与瀑布链风险
真实加载顺序取决于它出现的位置和上下文：
- 出现在外部 CSS 文件（如 main.css）中 → 必须等 main.css 下载 + 字节流解析到该行，才发起下一个请求
- 出现在 <style> 块中 → 等整个 <style> 内容解析完毕，CSSOM 构建中途暂停，去 fetch 导入资源
- 多层嵌套（A.css @import B.css，B.css 又 @import C.css）→ 形成严格 A→B→C 串行链，HTTP/1.1 下极易占满连接池
- 在 media 查询内使用（如 @import url("print.css") print;）→ 仍会下载，只是不参与初始 CSSOM 构建，但依然阻塞后续同文件内的规则解析
如何让导入真正“并发”且可控
唯一可靠方式是把导入逻辑从 CSS 移到 HTML 层：
- 用多个 <link rel="stylesheet"> 替代 CSS 内的 @import，浏览器可并行发起所有请求
- 关键样式用 rel="preload" as="style" 提前触发下载，再用 <link rel="stylesheet"> 应用
- 条件加载（如暗色模式）改用 JS 动态插入 <link>，配合 media 属性切换，避免无条件加载
- 构建时用 PostCSS 或 Webpack 的 css-loader 将 @import 提前展开为内联或拆分 <link>，别留到运行时
查漏补缺：老项目里怎么揪出隐藏的 @import
容易被忽略的是第三方依赖里的 @import，尤其 node_modules 中的 UI 库：
- 运行 grep -r "@import" src/ node_modules/，重点关注 .css 文件
- Chrome DevTools Network 面板中观察 CSS 请求是否呈“阶梯状”排列（时间轴上明显错开）
- 打开 Coverage 面板，若某 CSS 文件加载极慢但内容极少，大概率是被前面的 @import 卡住
- 使用 critical 工具提取首屏 CSS 时，若结果为空或缺失，说明关键样式被 @import 链延迟加载了
真正影响首屏速度的，往往不是你写的那几行 @import，而是它悄悄拖慢了整个 CSSOM 构建节奏——而这个节奏，浏览器不会告诉你它卡在哪，只会让你看到白屏多停留了 300ms。
