<link> 总是比 @import 更可靠，因为它是 HTML 原生标签，解析即发起请求；而 @import 是 CSS 规则，依赖父样式表加载后才串行触发，易导致 FOUC、阻塞渲染、不支持 preload 等性能缺陷。
为什么 <link> 总是比 @import 更可靠
因为 <link> 是 HTML 原生标签，浏览器一解析到就立刻发起 CSS 请求；而 @import 是 CSS 规则，必须等父样式表（或 <style> 块）加载并开始解析后才触发，属于串行依赖。这意味着：即使你写了两个 @import，第二个也得等第一个下载、解析完才能启动——实际加载时间可能翻倍。
常见错误现象：@import 在网速慢或资源多时导致页面“白屏几秒后再突然渲染样式”，即所谓 FOUC（Flash of Unstyled Content）。这不是 bug，是设计使然。
-
<link>支持rel="preload"提前拉取关键 CSS，@import完全不支持 -
@import必须写在 CSS 文件最顶部（或<style>的第一行），否则被忽略；<link>位置自由，只要在<head>内即可 - 现代构建工具（如 Webpack、Vite）默认不会处理
@import的跨文件依赖，容易漏打包
@import 在 CSS 文件里还能用吗
技术上可以，但不推荐。它只在两种场景下勉强成立：一是维护遗留 CSS 库（比如某些老的 Bootstrap 版本），二是极小项目中做逻辑分块（例如 @import "vars.css"; @import "base.css";）。
问题在于：CSS 预处理器（Sass/Less）的 @import 和原生 CSS 的 @import 不是一回事。前者是编译期合并，后者是运行时请求——很多人混淆这点，误以为写 Sass 的 @import 就等于优化了加载。
立即学习“前端免费学习笔记（深入）”；
- 纯 CSS 中的
@import会阻塞后续样式的解析，哪怕只是@import url("print.css") print;也会拖慢屏幕样式渲染 - 如果父 CSS 文件用了
HTTP/2 Server Push，@import的资源仍无法被推送，而<link>可以显式声明rel="preload" - 所有主流 Lighthouse、WebPageTest 性能检测工具，遇到
@import都会标为“潜在渲染阻塞”
动态插入样式时只能用 <link>
JavaScript 操作 DOM 插入新样式，唯一可行方式是创建 <link> 元素。因为 @import 不是 DOM 节点，不能通过 document.createElement 或 insertRule 注入。
典型使用场景：主题切换、A/B 测试加载不同 CSS、按需加载组件样式。
- 正确写法：
const link = document.createElement('link'); link.rel = 'stylesheet'; link.href = 'dark-theme.css'; document.head.appendChild(link); - 试图用 JS 拼接
@import字符串注入<style>，会导致该规则被忽略（除非整个<style>是新创建的且内容完整） -
document.styleSheetsAPI 只能读取已加载的样式表，无法对@import的子表做独立控制
<link> 的额外能力是 @import 根本没有的
<link> 不只是“引入 CSS”，它是 HTML 资源链接的通用接口。这个差异直接决定架构灵活性。
- 可定义图标：
<link rel="icon" href="favicon.ico">，@import连想都不要想 - 可预加载关键资源：
<link rel="preload" href="critical.css" as="style">，@import无对应机制 - 可声明媒体查询：
<link rel="stylesheet" href="print.css" media="print">，而@import的媒体条件写法（@import url("print.css") print;）仍会触发下载，只是不应用 - 支持
integrity和crossorigin属性做 Subresource Integrity 校验，@import完全不支持
真正容易被忽略的点：当多个 <link> 并列存在时，它们的加载是并发的；而 @import 在任何上下文中都是递归串行的——哪怕你把它写进一个被 <link> 加载的 CSS 里，它依然要排队。这个底层加载模型差异，决定了你在性能敏感场景下几乎没有理由选择 @import。
