@import是同步阻塞式加载，按顺序串行请求，性能远差于并行的<link>；仅适用于条件加载，分层管理应优先用预处理器或JS模块化方案。
多个 @import 的加载顺序和阻塞问题
CSS 中的 @import 是同步、阻塞式加载，浏览器会按顺序逐个下载并解析导入的样式表，前一个没加载完，后一个根本不会发起请求。这意味着如果你写了 3 个 @import，实际是串行加载，比直接用多个 <link> 标签慢得多，尤其在弱网下更明显。
- 别在
main.css开头堆叠@import url("reset.css"); @import url("base.css"); @import url("theme.css");—— 这等于把关键 CSS 拆成三轮 HTTP 请求 - 如果必须分层（比如主题切换），优先用
<link rel="stylesheet" href="..." media="..."></link>配合media或 JS 动态切换，而不是靠@import组织依赖 -
@import只能在 CSS 文件顶部或<style>块最开头写，放在规则后面会被忽略（比如写在.btn { ... }后面，浏览器直接跳过）
@import 在不同上下文中的写法差异
它在外部 CSS 文件里和内联 <style> 里行为一致，但路径解析逻辑不同：外部文件中 @import 的相对路径，是相对于该 CSS 文件自身位置，不是 HTML 页面；而内联 <style> 中的 @import，路径则相对于当前 HTML 页面 URL。
- 外部 CSS：
styles/base.css里写@import "variables.css";→ 加载的是styles/variables.css - HTML 内联：
<style>@import "variables.css";</style>→ 加载的是跟 HTML 同目录下的variables.css - 支持带媒体查询：
@import "print.css" print;或@import "mobile.css" (max-width: 768px);，但注意括号前后不能有空格，否则语法错误
为什么 @import 不适合做“样式分层”管理
所谓“分层”，比如把重置、基础组件、布局、主题分开维护，听起来合理，但用 @import 实现反而掩盖了真实依赖关系，且无法利用现代构建工具的 tree-shaking 或 scope 处理。
- Webpack/Vite 等默认不解析 CSS 中的
@import（除非显式配css-loader的import选项），导致你本地开发看着正常，打包后样式丢失 - PostCSS 插件如
postcss-import能处理，但它是在构建时把所有@import内联展开——最终输出的还是单个 CSS 文件，分层只存在于源码，对运行时无意义 - 真正需要分层时，更可靠的做法是用预处理器（如 Sass 的
@use/@forward）或 CSS Modules + JS import 控制作用域和加载时机
替代方案：什么时候该用 <link> 而不是 @import
只要不是为了条件加载（比如仅打印时引入），所有常规样式表都应该用 <link>。它支持 preload、as="style"、onload 回调，还能被浏览器并行下载。
立即学习“前端免费学习笔记（深入）”；
- HTML 中这样写：
<link rel="stylesheet" href="reset.css"><link rel="stylesheet" href="base.css">—— 浏览器会并发请求 - 想控制加载优先级？加
rel="preload" as="style" onload="this.rel='stylesheet'"，再配合<noscript>降级 - 动态换主题？改
<link id="theme">的href属性，比反复插入/删除@import更稳定
@import 最常出问题的地方不是语法写错，而是误以为它能像 JS 的 import 那样做模块化管理——它不能，也不该承担这个角色。 
