在网页样式管理中，将基础规范、布局框架与业务模块样式拆分到不同文件，再通过主样式表统一调度，是一种常见做法。CSS提供的@import规则允许在一个样式文件内部引入其他样式文件，从而形成层级化的样式结构。理解它与link标签的差异，以及它在加载过程中的实际表现，是合理运用的前提。
@import的基本语法与工作方式
@import必须写在CSS文件的最前面，位于任何规则之外，其后可以指定媒体类型。它的作用是告诉浏览器：当前样式文件依赖另一个样式文件，需要先加载并执行被引入的文件，再处理后续规则。这种机制在单文件内实现了多文件的逻辑聚合。
下面是一段主样式文件的示例，通过@import引入了重置样式和布局样式两个子样式：
/* main.css 主样式 */
@import url("reset.css");
@import url("layout.css") screen;
body {
font-family: "PingFang SC", sans-serif;
}
需要注意的是，如果在规则之后写@import，浏览器会直接忽略该语句。此外，@import支持媒体查询参数，这意味着你可以针对不同的设备仅加载对应的子样式，从逻辑上减少不必要样式的解析。
主样式与子样式组合的组织策略
采用主样式配合@import子样式的核心目的通常不是性能加速，而是工程层面的模块拆分。比如将颜色变量、按钮组件、表单样式分别放到不同子文件中，主样式只做引用汇总，团队成员能快速定位代码。这种结构在后期维护时优势明显。
一个推荐的目录划分方式如下：主样式负责全局引用，子样式按功能解耦。这样可以避免单个CSS文件过大导致编辑困难。示例结构对应的引入代码为：
/* app.css */
@import url("variables.css");
@import url("buttons.css");
@import url("forms.css");
不过，这种组合方式如果直接投放到生产环境，会因为每个@import都产生一次额外请求而影响速度。因此很多项目会在构建阶段使用工具将@import内联，既保留开发时的拆分便利，又避免运行时的串行请求开销。
加载性能的真实表现与优化思路
浏览器处理link标签时可以与页面其他资源并行请求，而@import在主样式返回后才会发起子样式请求，形成串行。如果主样式较大或网络延迟高，子样式就会明显滞后，造成页面样式闪烁甚至无样式内容闪现。
我们用一段对比代码说明两种引入方式在HTML中的差异：
<!-- 方式一：link并行 -->
<link rel="stylesheet" href="reset.css">
<link rel="stylesheet" href="layout.css">
<!-- 方式二：主样式内@import -->
<link rel="stylesheet" href="main.css">
<!-- main.css中包含@import url("reset.css"); 等 -->
优化加载的正确思路是：开发期用@import做结构分层，构建期通过PostCSS或Webpack等工具把子样式合并进主样式，最终上线只保留一个或极少数CSS文件。若必须保留@import，应控制子样式数量，并把首屏关键样式内联到页面head中。
常见误区与适用场景总结
不少初学者认为@import能减少HTTP请求，这其实是误解。未经处理的@import反而增加请求且串行化。真正减少请求的是构建合并，而非@import本身。另一个误区是滥用媒体查询@import，以为能省流量，但浏览器仍会下载全部文件只是不应用。
适合使用主样式加@import组合的场景包括：多主题切换系统中主样式引入不同主题子文件、大型后台系统按菜单模块拆分样式便于协作。在这些场景下，逻辑清晰的价值高于微小的加载差异，配合构建优化即可兼顾两者。