@import 在现代 css 架构中基本不该使用，因其导致样式串行阻塞加载、破坏热更新、不支持条件导入、构建工具无法识别依赖；应改用 postcss-import 构建时内联合并，并配合 css modules 或自定义属性实现作用域隔离与可维护性。
为什么 @import 在现代 CSS 架构里基本不该用
它会让样式加载变成串行阻塞，浏览器必须下载、解析完一个 @import 的文件，才能继续处理后续样式。哪怕只是分层管理，也直接拖慢首屏渲染——尤其在移动端或弱网下，白屏时间明显变长。
常见错误现象：main.css 里写了 @import "base/variables.css";，但变量根本没生效；或者热更新时改了 mixins.css，页面样式却没刷新。
- 所有
@import必须写在样式表最前面（CSS 规范强制），否则会被忽略 - 它不支持媒体查询条件嵌套（
@import url("print.css") print;虽然语法合法，但实际兼容性差，safari 旧版会直接跳过） - webpack/Vite 等构建工具默认把
@import当作普通字符串处理，不会做依赖分析和 HMR，导致局部修改需全量重载
CSS 分层管理的替代方案：用构建工具做 postcss-import
真正能实现“逻辑分层 + 物理合并 + 按需注入”的，是构建时的 postcss-import 插件。它把 @import 提前展开成内联内容，最终只输出一个无 @import 的 CSS 文件。
使用场景：你有一套 src/css/ 目录结构，含 base/、components/、pages/ 子目录，想按需组合不同入口。
立即学习“前端免费学习笔记（深入）”；
- 安装后在 PostCSS 配置中启用：
require('postcss-import') - 在主样式文件里写
@import "base/variables.css";—— 注意路径是相对于postcss-import的from参数或root配置 - 变量、mixin 等声明类内容必须放在被 import 的文件顶部，否则可能因展开顺序错乱导致
Unknown word错误
真正影响可维护性的不是“分层”，而是“作用域失控”
很多人以为用 @import 把样式拆开就等于可维护，结果换来的是全局选择器泛滥、命名冲突、覆盖难追溯。CSS 本身没有模块概念，靠文件切分解决不了本质问题。
性能与兼容性影响：即使用了 postcss-import，如果仍大量使用 div > ul li a:hover 这类强耦合选择器，组件复用时照样崩。
- 优先用 BEM 或 CSS Modules（
.Button--primary或:local(.icon)）隔离样式作用域 - 把颜色、间距、断点等抽成 CSS 自定义属性（
--color-primary），而非重复写#007bff - 避免在
@import后续文件里用!important覆盖前面导入的内容——这会让依赖关系彻底不可读
什么时候可以破例用原生 @import
极少，仅限两个场景：需要动态加载第三方主题 CSS（如暗色模式切换），或必须保持外部 CDN 样式独立缓存（比如接入 SaaS 厂商的 UI 组件包）。
容易踩的坑：用 @import 加载本地文件时，路径写成相对当前 HTML 页面，而不是相对 CSS 文件——浏览器解析依据是 <link> 所在 CSS 的位置，不是 HTML。
- 正确写法：
@import "./theme/dark.css";（假设该语句在app.css中） - 错误写法：
@import "../src/css/theme/dark.css";（路径越界，404 是常态） - 若真要动态加载，用 js 控制
<link rel="stylesheet">更可控，还能加onload回调
CSS 可维护性的核心不在“怎么拆”，而在“怎么锁住作用域、怎么收敛变量、怎么让修改范围可预期”。@import 看似分层，实则把耦合从代码挪到了加载链路上。