link标签是现代项目中引入CSS的唯一推荐方式，@import应避免在关键路径使用；因其并行下载、支持preload和media条件加载、可JS动态插入且无兼容风险，而@import强制串行阻塞、引发FOUC、不支持动态注入和条件跳过，弱网下首屏延迟可达800ms+。
直接说结论：link 标签是现代项目中引入 CSS 的唯一推荐方式，@import 应该避免在关键路径中使用，尤其不能用于首屏样式。
为什么 link 加载更快且更可控
浏览器解析 HTML 时，遇到 <link rel="stylesheet"> 就立刻发起请求，并与其他资源（JS、图片）并行下载；而 @import 是 CSS 规则，必须等父样式表下载完成、解析到那一行才开始下一个请求——这形成隐式串行链。
- 常见错误现象：
a.css里写@import url("b.css"); @import url("c.css");，结果是 b 下完 → 解析 → c 下完 → 解析，总耗时不等于并行，而是接近三者之和 - 实测数据（Chrome DevTools + 3G 模拟）：5 个 CSS 全用
link比嵌套 4 层@import快 300–600ms；弱网下首屏延迟可差 800ms+ -
link支持rel="preload"提前拉取关键 CSS，@import完全不支持
@import 在哪些地方会静默失效或行为异常
@import 不是 HTML 语法，它只能出现在 CSS 文件顶部或 <style> 块的最开头；写在任何 CSS 规则之后，整条语句会被浏览器静默丢弃。
- 写在
<style>中但不在第一行？无效 - 用 JS 动态注入：
style.textContent = '@import url(theme.css)';？不会触发下载，控制台无报错，但样式不生效 - 媒体查询写法
@import url("mobile.css") screen and (max-width: 768px);？语法合法，但浏览器仍会无差别下载该文件，只是不应用——浪费带宽 - Gmail 等邮件客户端会直接剥离
@import，只保留link或内联样式（但多数邮件客户端也不支持link，所以实际靠内联）
什么时候还能勉强用 @import？
几乎没有必须用它的场景。仅在两种极窄条件下可考虑，且需清楚代价：
立即学习“前端免费学习笔记（深入）”；
- 维护遗留 Sass/Less 项目时，用
@import做模块拆分——但最终应由构建工具（如 Webpack/Vite）编译合并为单个link可加载的文件 - 需要基于
@supports或@media上下文做条件导入（例如@import "dark.css" (prefers-color-scheme: dark);），但注意：即使不匹配，文件依然被下载
真正需要条件加载时，应优先用 <link href="dark.css" media="prefers-color-scheme: dark">，浏览器会跳过下载直到匹配。
动态切换主题或按需加载只能靠 link
运行时想换主题、加载组件样式？唯一可行路径是操作 DOM：
const link = document.createElement('link');link.rel = 'stylesheet'; link.href = 'theme-dark.css';document.head.appendChild(link);
@import 是纯静态规则，无法被 JS 创建、修改或删除。现代 CSS-in-JS 方案（如 styled-components）底层也只操作 <style> 或 <link>，从不生成 @import 字符串。
最容易被忽略的一点：哪怕你没手动写 @import，只要引入的第三方 CSS 文件内部用了它（比如某些老旧 UI 库），就会把你的关键渲染路径拖慢——务必用 Network 面板检查瀑布流，确认没有隐式串行依赖。
