@import拖慢首屏渲染，因其是同步阻塞行为：浏览器必须下载解析完当前CSS才能发起下一层@import请求，形成串行瀑布链（如main.css→base.css→theme.css），而<link>可并行加载；实测5个CSS用@import延迟600ms+，改用<link>降至220ms。
为什么@import在生产环境会拖慢首屏渲染
@import 是同步阻塞行为：浏览器必须下载、解析完当前 CSS 文件，才能读取其中的 @import 规则并发起下一次请求。这意味着多层 @import 会强制串行加载，比如 main.css → base.css → utils.css → theme.css，每个环节都要等前一个完成，首屏样式就卡在最后一步。
而 <link rel="stylesheet"> 是并行加载的，浏览器在解析 HTML 时就能预发现所有 <link> 并发请求，实际耗时接近最长那个文件，不是总和。
- 实测：5 个 20KB 的 CSS 文件用
@import链式加载，首屏样式生效平均延迟 600ms+；改用 5 个独立<link>后降至 220ms 左右 -
@import不进 HTML 预加载器队列，Network 面板里显示为 “late” 请求，无法被<link rel="preload">提前触发 - 即使只写一层
@import，它仍比同位置<link>多一次解析跳转，有不可忽略的调度开销
@import引发FOUC且调试困难
FOUC（Flash of Unstyled Content）不是偶尔发生，而是确定性风险：@import 加载期间，DOM 已就绪但 CSSOM 没构建完，浏览器会先渲染无样式的页面，等 @import 资源返回才重绘——尤其在弱网或高延迟 CDN 下，白屏或错乱布局肉眼可见。
更麻烦的是，它几乎不报错：
立即学习“前端免费学习笔记（深入）”；
- CSS 文件 404 或返回 500 时，整个
@import块被浏览器静默丢弃，控制台无任何提示 - 路径写错（如漏掉
./或后缀）时，开发工具可能不报错，只让样式“消失” - 嵌套超过 3 层后，部分旧版 Safari 会直接忽略后续导入，且无 warning
跨域场景下@import根本不可用
想从 CDN 引入第三方 CSS？@import 在跨域时必然失败，不是配置问题，是规范限制：
- 它无法携带
crossorigin属性，浏览器不会以 CORS 模式发起请求 - 即使服务端正确返回了
Access-Control-Allow-Origin，响应内容仍被 CSS 解析器视为 “opaque”，直接丢弃 - 唯一可行方案是改用
<link rel="stylesheet" crossorigin>，并确保服务端响应头匹配
你没法 hack 这个行为，也没法靠 polyfill 补救——这是浏览器引擎级的硬性拦截。
微信小程序和 Shadow DOM 中的@import陷阱
不同运行环境对 @import 的处理差异极大，容易误以为“写法一样就能通用”：
- 微信小程序中，
@import只在.wxss文件里有效，写在.wxml或.js里完全无效；路径必须带.wxss后缀且不能用绝对路径（/styles/a.wxss会被忽略） - Shadow DOM 中，
@import在shadowRoot.innerHTML = '<style>@import ...</style>'里会卡住首屏，延迟 300–600ms，且路径基于 HTML 文档 URL 解析，不是组件 JS 所在位置——极易 404 - 原生 Web Components 正确做法是用
adoptedStyleSheetsAPI 动态注入，而非依赖 CSS 语法级导入
真正麻烦的不是“怎么写对”，而是“同一套写法在不同上下文里，失效方式完全不同，且错误信号极弱”。
