结论：改用 @use 替代原生 @import。@use 实现作用域隔离，避免变量冲突与样式覆盖，防止重复编译，提升构建效率与可维护性。
怎么让 Sass 的 @import 不变成维护噩梦
直接说结论：别用原生 @import，改用 @use。CSS 文件越长、团队越大，原生 @import 越容易导致变量冲突、样式覆盖不可控、构建时重复编译。
常见错误现象：@import 后变量被后导入文件意外覆盖；某处改了 $primary-color，整个项目按钮颜色全变；CI 构建时间突然翻倍——其实是同一套工具函数被反复解析十几次。
-
@use强制作用域隔离，每个模块的变量、混合宏默认不泄漏 - 必须显式
as *或重命名才能访问，比如@use 'mixins/breakpoints' as bp - 同一文件多次
@use只加载一次，避免重复计算和冗余输出 - 不兼容旧版 Dart Sass（
Sass 模块化目录结构怎么分才不反人类
不是“按功能分文件夹”就万事大吉。真实协作中，最常出问题的是“基础层”和“组件层”的耦合——比如 _variables.scss 里塞了 $header-height，结果某个组件自己又定义同名变量，@use 后谁生效全看顺序。
- 只在
base/下放真正全局的、不变的配置：$color-blue-500、$radius-sm，不放业务相关值 - 把组件专属样式拆进独立模块，如
components/_card.scss，内部用@use '../base/variables' with ($radius-sm: 6px)局部覆盖 - 避免
utils/下堆满_helpers.scss、_functions.scss——按用途聚合，比如utils/_text-scale.scss只管字号阶梯，utils/_spacing.scss只管rem倍数映射 - 所有模块顶层加
@forward统一出口，比如index.scss里写@forward 'base/variables'; @forward 'utils/text-scale';，上层只@use 'styles/index' as s
为什么 @use 后混合宏（@mixin）调用总报错
错误信息通常是：Undefined mixin. 或 No mixin named xxx。根本原因不是没写，而是没正确暴露或没正确引入。
立即学习“前端免费学习笔记（深入）”；
- 混合宏必须在定义它的文件里显式
@forward出来，光写@mixin foo不够 - 调用方要通过命名空间访问，比如
@include utils.text-truncate;，不能直接@include text-truncate; - 如果想省略命名空间，得在
@use时加as *，但仅限单个模块，多个as *会引发命名冲突 - 注意：Dart Sass 1.40+ 支持
@use 'x' with (…)传参给混合宏的默认参数，但不支持运行时动态传参，别指望它替代 JS 逻辑
Webpack/Vite 里 Sass 模块化怎么配才不崩
构建工具本身不处理 @use 逻辑，崩点通常在 loader 配置或路径别名上。最典型的是 Vite 项目里 @use 'base/variables' 报错 “file not found”，其实是因为没配 scss.additionalData 或别名没透到 Sass 解析层。
- Vite 用户：在
vite.config.ts的css.preprocessorOptions.scss下加additionalData: '@use "@/styles/index" as *;'，确保所有单文件组件自动继承基础模块 - Webpack 用户：检查
sass-loader版本是否 ≥ 12.0，旧版不识别@use；同时确认resolve.alias里的@别名已同步到sassOptions.includePaths - 绝对路径导入（如
@use '/src/styles/base/variables'）在某些 CI 环境下会因工作目录不同而失效，一律改用相对路径或配置好的别名 - 启用
sourceMap: true后，Sass 模块化调试体验提升明显，但开发环境外建议关掉，影响构建体积
模块化不是加几个 @use 就完事，关键在变量生命周期管理——哪个模块能改值、哪个只能读、改了影响范围有多大，这些得靠约束，而不是靠人记。没约束的模块化，只是把混乱从一个文件搬到了十个文件里。
