@import 会让 CSS 构建变慢又难调试，因其是运行时加载、无法静态分析依赖，导致工具链无法合并压缩样式，触发多次请求、来源映射错乱、热更新失效，且 css-loader 与 postcss-import 易冲突。
为什么 @import 会让 CSS 构建变慢又难调试
因为 @import 是运行时加载，不是构建时解析——Webpack、Vite 或 PostCSS 在处理它时无法静态分析依赖关系，导致无法合并、压缩、提取或复用样式块。浏览器拿到的仍是嵌套 @import 链，可能触发多次 HTTP 请求（尤其未启用 HTTP/2），且 DevTools 中的来源映射错乱，定位样式来源困难。
- 开发时改一个
_mixins.css，结果整个theme.css→base.css→_mixins.css链路全要重载 - PostCSS 插件（如
postcss-import）默认不展开嵌套@import，除非显式配置depth: Infinity - CSS 模块化（如
css-loader的modules）对@import内部选择器无效，作用域不隔离
用 postcss-import 替代原生 @import 实现扁平化
预编译阶段把所有 @import 内联展开成单层 CSS，后续工具链（Autoprefixer、CSSNano）才能统一处理。关键不是禁用 @import，而是让它的行为变成“文本插入”而非“资源引用”。
- 安装：
npm install postcss-import --save-dev - 在
postcss.config.js中前置声明：require('postcss-import')，顺序必须在autoprefixer和cssnano之前 - 路径解析基于
from文件位置，不是当前@import所在文件——所以推荐用相对路径或别名（如@import 'base/variables'需配resolve: { alias: { base: './src/css/base' } }） - 不支持
@import url(...)这类带协议或绝对 URL 的写法，会跳过处理
Webpack 场景下避免 css-loader 二次解析 @import
css-loader 默认会尝试解析并请求 @import 资源，和 postcss-import 形成冲突：前者发 HTTP 请求，后者做文本替换，结果要么报 404，要么样式重复注入。
- 关闭
css-loader的import功能：{ loader: 'css-loader', options: { import: false } } - 确保
postcss-loader在css-loader之前执行（Webpack rule 中顺序从右到左） - 如果用了
MiniCssExtractPlugin，注意它不改变处理顺序，只影响输出方式 - Vite 用户不用手动配 —— 它默认启用
postcss-import，但需确认vite.config.ts中没显式关掉css.devSourcemap，否则展开后定位不到原始文件
SCSS/Less 用户其实更简单：直接停用 @import 改用 @use 或 @forward
SCSS 6+ 推荐的 @use 本质是模块化导入，天然支持命名空间、变量隔离和静态分析；@forward 则用于透传依赖，两者都由编译器在构建时解析，不会产生运行时链路。
立即学习“前端免费学习笔记（深入）”；
-
@use 'base/variables' as var→ 变量访问变成var.$color-primary，避免全局污染 -
@forward 'components/button'+@use 'design-system' as ds→ds.button-styles可控导出 - 旧项目迁移时，
@import不会立刻报错，但 Webpack/SCSS 编译器会警告 “@import rules are deprecated, use @use instead” - Less 无等价机制，只能靠构建脚本提前用
less-plugin-inline展开，不如换 SCSS 省心
postcss-import 的 from 是入口 CSS 文件路径，不是 @import 当前行所在文件，跨目录引用时容易漏配 resolve 或误用相对路径。 
