@forward 比 @import 更适合组件库导出，因其仅暴露变量、混合宏和函数声明而不注入CSS，避免样式污染与重复编译；@import 则立即执行并泄露样式到全局，易引发冲突。
为什么 @forward 比 @import 更适合组件库导出
因为 @forward 不会立即加载样式，只暴露变量、混合宏和函数的声明，避免意外样式污染和重复编译。而 @import 一执行就注入 CSS，组件内部样式可能提前泄露到全局作用域，尤其在多个组件共用基础模块时容易冲突。
典型场景：你维护一个 _buttons.scss，它依赖 _mixins.scss 和 _vars.scss；用户只需 @use "buttons"，但你希望他们也能直接访问 $primary-color 或 fluid-type() —— 这时 @forward 是唯一干净的出口机制。
-
@forward "mixins"导出全部内容（默认行为） -
@forward "vars" as var-*统一加前缀，防止命名冲突 -
@forward "theme" hide $dark-mode主动隐藏不对外暴露的内部变量
@forward 的路径别名与包结构对齐技巧
SCSS 不支持 Node.js 式的包解析，所以 @forward "core/vars" 要求路径真实存在，不能靠 package.json#exports 或别名配置自动映射。这意味着你的文件夹结构必须显式反映使用者的引用路径。
常见错误：开发者把所有基础文件放在 src/scss/core/_index.scss，然后想用 @forward "core" 一次性导出——不行，@forward 后面必须是具体文件或目录，且结尾不能带 .scss，也不能是空目录。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：建立
core/_index.scss，里面写@forward "vars"; @forward "mixins";，再统一@forward "core/index" - 推荐结构：
index.scss（主入口）→components/_index.scss→ 各组件子文件，保持层级扁平 - 注意：VS Code 的 SCSS 插件可能无法跳转
@forward导出的内容，这是已知局限，不是你配错了
如何用 @use + @forward 实现“按需导出 + 命名空间隔离”
用户 @use "ui" 后拿到的是命名空间对象，比如 ui.$spacing-sm，而不是全局 $spacing-sm。这要求你在 @forward 时主动控制命名空间粒度——导出太粗（全 forward）会丧失隔离性，太细（每个都 as xxx-*）又增加维护成本。
真实项目中更稳妥的做法是分层导出：基础原子模块（颜色、断点）用 as core-*，组件级模块（button、card）保留原名，工具类（helpers、layout）用 as util-*。
-
@forward "core/vars" as core-*;→ 使用时写core.$primary -
@forward "components/button";→ 使用时写button.button()（前提是 button/_index.scss 里@use "mixins" as *） - 禁止在
@forward后再跟@use同一模块：会导致重复定义警告，SCSS 不允许同一模块被多次引入（即使路径不同）
构建时的副作用：@forward 不等于零成本
虽然 @forward 本身不生成 CSS，但它仍会触发被转发文件的解析和符号注册。如果你转发了一个含大量 @function 的文件，而用户根本没调用其中任何一个函数，这些函数仍会占用编译内存。
更隐蔽的问题是循环转发：A @forward "B"，B @forward "C"，C 又 @forward "A" —— Dart Sass 会报 "Circular @forward dependency"，但错误堆栈极难定位，往往要逐个注释 @forward 才能排查。
- 检查转发链：运行
sass --watch src/:dist/ --trace可看到完整依赖图 - 避免跨层转发：不要让
components/_index.scss转发core/typography，应由core/_index.scss统一管理 - 真正“按需”的边界在
@use端：只有被@use的模块才会参与编译，转发只是开放权限，不等于强制加载
最常被忽略的一点：@forward 不能转发 CSS 规则（即不能转发选择器块），它只处理声明（variables/mixins/functions）。如果误以为它能替代 @import 来聚合样式，结果就是什么 CSS 都没出来。
