@use是Sass官方强制替代@import的模块化方案，因@import已被Dart Sass 2.0+完全移除；它通过命名空间（如variables.$primary-color）避免全局污染，要求@use置于文件顶部、路径带引号且不自动补扩展名，变量访问必须加前缀。
Webpack 中配置 Sass/Less 的 @use 和 @import
Webpack 本身不处理预处理器语法，必须靠 sass-loader 或 less-loader 解析。默认情况下，@import 仍可用，但已被官方标记为过时；现代项目应优先用 @use（Sass）或 @forward（Sass）替代。
关键点是 loader 配置要启用 api: 'modern'（Sass）或确保 Less 版本 ≥ 4.0（支持 @use）。否则 @use 'variables' 会报错 Unknown rule '@use'。
-
sass-loaderv14+ 默认启用 modern API，无需额外配置；若用旧版，需显式设置implementation: require('sass')并确认 sass 包版本 ≥ 1.33 - Less 用户注意：
@use在 Less v4.0+ 才支持，v3.x 只能继续用@import，且不支持命名空间隔离 -
@use导入的变量/混入默认带命名空间（如vars.$primary），避免命名冲突；@import是全局注入，容易覆盖同名变量
Vite 里 Sass 模块化导入无需额外配置
Vite 内置支持 Sass/Less，开箱即用，但默认行为仍基于传统 @import。要启用真正的模块化语义（比如作用域隔离、自动命名空间），你得主动写 @use，而不是依赖 Vite 自动转换。
常见误区是以为 Vite “自动支持模块化”，其实它只是把 Sass 编译通了——@use 是否生效，完全取决于你写的语法和底层 Sass 版本。
立即学习“前端免费学习笔记（深入）”；
- 检查项目中
sass包版本：npm list sass，低于1.33.0无法解析@use - Vite 不干涉
@use的解析逻辑，也不提供类似 CSS Modules 的类名哈希；它只保证编译成功 - 若搭配
postcss-nested等插件，注意它们与@use的兼容性：某些旧插件会破坏嵌套 + 命名空间组合
SCSS 文件命名与 @use 路径解析规则
Sass 的 @use 对路径非常敏感，尤其在多层目录结构下。它不按 Webpack 的 resolve.alias 工作，而是遵循 Sass 官方的“加载器链”（loader chain）规则。
例如 @use '@/styles/variables' 失败，不是因为路径错，而是因为 @/ 是 Webpack 别名，Sass loader 根本不认识。
- 正确做法：用相对路径（
@use '../styles/variables'）或配置 Sass 的includePaths（在sass-loaderoptions 里加includePaths: ['src/styles']） - 文件名带下划线前缀（如
_variables.scss）表示“partial”，不能直接被@use加载，必须去掉_（@use 'variables'） - 同一文件多次
@use不会重复编译，Sass 会缓存模块实例；但@import每次都重新解析，易引发变量重定义错误
混入（mixin）跨模块复用的坑
用 @use 引入含混入的 SCSS 文件后，必须通过命名空间调用，比如 theme.text-style()。直接写 text-style() 会报错 Mixin "text-style" is not found。
更隐蔽的问题是：混入内部引用的变量，如果来自另一个模块，必须显式 @use 该模块，不能靠“传递依赖”自动获取。
- 错误写法：
@use 'theme'; @use 'utils'; .btn { @include theme.button(); }—— 若button()内部用了utils的函数，会失败 - 正确写法：在
theme.scss里也写@use 'utils'，或者导出时用@forward 'utils' - 别试图用
@import混合@use：Sass 不允许在同一个文件里混用两种导入机制，会触发Invalid CSS错误
@use 替代 @import、是否为每个 partial 显式声明依赖、是否接受命名空间带来的冗余写法。这些约束看起来麻烦，但正是它们堵住了变量污染和隐式耦合的缺口。 
