@use 是组件库模块化的唯一可靠路径，它强制封装作用域、支持命名空间隔离、确保 tree-shaking，并需配合 _index.scss 作为入口契约，禁用 @import 防止全局污染。
直接用 @use 替代 @import，配合局部文件（_variables.scss、_mixins.scss、_button.scss）组织结构，是 Sass 实现组件库级模块化的唯一可靠路径。旧式 @import 已被弃用，它会污染全局作用域、无法控制命名空间、构建时无法 tree-shake。
为什么 @use 是组件库设计的硬性前提
@use 强制封装作用域：所有变量、函数、mixin 默认私有，必须显式 public 或通过 as * 暴露；每个 @use 语句生成独立命名空间，比如 @use 'base/variables' as vars 后，必须写 vars.$primary-color 才能访问——这天然防止命名冲突。
- 旧项目升级时，
@import引入的_mixins.scss可能被多个文件重复解析，导致 CSS 重复输出；@use保证只解析一次 - 组件库发布时，用户
@use 'my-lib/button'就只拿到 button 相关样式和 API，不会意外引入 layout 或 typography 规则 - VS Code + Dart Sass 插件能自动跳转到
@use的源文件，而@import常报“未找到定义”
_index.scss 文件不是可选，而是组件库入口契约
每个功能目录（如 components/、utilities/）必须配一个 _index.scss，里面只做两件事：用 @use 汇总子模块，用 @forward 对外暴露公共 API。不手动写这个文件，下游就无法干净地 @use 'my-lib/components'。
-
@forward 'button' shown $size-sm, $size-md;—— 只转发指定变量，隐藏内部$size-lg -
@forward 'button' as btn-*;—— 把 button 的所有公开成员加前缀，避免和用户项目变量名撞车 - 禁止在
_index.scss中写任何实际样式规则或@include，它只是路由表
CSS 输出体积失控？检查 @use 链路中是否混入了 @import
哪怕只有一处 @import 'reset' 被遗留，整个依赖链都会退化为全局作用域，Sass 将无法判断哪些 mixin 实际被调用，tree-shaking 失效，最终打包出全量 CSS。
立即学习“前端免费学习笔记（深入）”；
- 运行
sass --version确认是 Dart Sass 1.70+（支持完整@use语义），Node Sass 已不维护且无@use - Webpack 中若用
sass-loader，确保api: 'modern'且implementation指向sass（非node-sass） - 搜索项目里所有
@import，重点排查第三方依赖的node_modules是否含旧 Sass 文件——它们需用@use兼容层包裹
真正难的不是写对第一个 @use，而是让整个团队在新增组件时，下意识先建 _index.scss、再 @forward、绝不手写 @import。一旦松动，模块边界就从设计文档里消失，变成靠人肉约定维系的东西。
