sass/less的@import是编译期内容插入，非运行时加载；新版sass用@use/@forward替代以隔离作用域、避免污染；less可用@import(reference)仅声明不输出；中间件css合并应交由构建工具（如postcss）处理。
为什么@import在Sass/Less里不等于CSS的@import
因为 Sass 和 Less 的 @import 是编译期指令，不是运行时加载——它会把目标文件内容直接插入当前文件，再一起编译成单个 CSS。很多人误以为它像 Webpack 的 import 或 HTML 的 <link>，结果在构建后发现样式重复、变量污染、甚至编译报错。
- 真实场景：多个组件都
@import "_mixins.scss"，结果所有文件里都塞进同一份 mixin 定义，但 Sass 不报错，反而可能覆盖或静默失效 - 变量/函数作用域是“合并后全局”的，
$primary-color在 A.scss 里定义，在 B.scss 里修改，会影响 C.scss 中的使用结果 - 路径解析以入口文件为基准，不是相对于当前
@import所在文件（Less 默认如此，Sass 自 v5.0 起也统一为“从入口起算”）
Sass 的 @use + @forward 替代方案（v5.0+ 必须迁移）
旧版 @import 已被标记为 deprecated，新版 Sass 强制用 @use 控制命名空间和作用域。它不合并内容，而是按需导入，并隔离变量/函数/mixin。
-
@use "src/styles/mixins"→ 导入后必须写mixins.text-truncate()，避免冲突 -
@forward "src/styles/breakpoints"可在 index 文件中透出子模块，供上层统一@use "index" - 不支持循环依赖：
A.scss @use "B"且B.scss @use "A"会直接编译失败 - 性能影响：首次编译略慢（需解析依赖图），但增量编译更稳，且 CSS 输出体积通常更小（无重复代码）
Less 中如何安全复用中间件 CSS（如 normalize.css、postcss-reset）
Less 没有 @use，但可以用 @import (reference) 把公共样式“只声明不输出”，再配合 .mixin() 显式调用。
-
@import (reference) "normalize.less"→ 不生成任何 CSS，仅提供选择器和规则供extend或ruleset使用 - 若要注入 reset 样式，得手动写
#normalize() {}并在入口调用，不能靠@import自动展开 - 注意：(reference) 不影响变量作用域，所以
@import (reference)后仍能访问其@variables，这点和 Sass 的@use逻辑不同 - 常见坑：Webpack 的
less-loader默认开启javascriptEnabled: true，但某些内联 JS 逻辑（如~color计算）在 (reference) 模式下可能不执行
真正想“合并中间件 CSS”时，该交给谁做？
答案不是预处理器，而是构建工具链。Sass/Less 的职责是生成语义化、可维护的源码；合并、压缩、提取、source map 等属于打包阶段。
立即学习“前端免费学习笔记（深入）”；
- Webpack：用
MiniCssExtractPlugin抽离 CSS，配合css-loader的importLoaders处理@import链路 - Vite：默认已处理
@import合并，但需确认css.preprocessorOptions.less.javascriptEnabled是否关闭（生产环境应关） - PostCSS：如果中间件是纯 CSS（如 modern-normalize），直接用
postcss-import插件，比预处理器的@import更轻量、更可控 - 关键提醒：
@import "node_modules/some-lib/dist/index.css"在 Sass 中会被当作路径拼接失败（缺少~前缀），而 PostCSS 的postcss-import支持自动解析 node_modules
最常被忽略的一点：很多人花半天调 @import 路径，却没意识到——只要最终 CSS 是通过构建工具合并的，预处理器里的 @import 就不该承担“资源聚合”职责，而应该专注“逻辑组织”。
