使用@forward导出Sass模块，构建可维护CSS组件库

在构建Sass组件库时，@forward 规则常被误认为只是简单的“导出”工具。然而，它的核心功能远不止于此——它本质上是组件库对外暴露的接口控制开关。这个开关决定了哪些内部成员可以被外部世界访问，以及它们以何种名称、在哪个命名空间下被引用。理解这一机制，是避免后续一系列诡异报错的关键。

为什么 @forward 导出后变量还是找不到？

许多开发者遇到变量找不到的问题时，第一反应是检查路径或拼写。但实际上，方向往往错了。问题的根源在于误以为 @forward 会将内容“注入”到当前模块中。事实上，它只做一件事：将目标模块的内容“重新发布”出去。

举个例子，如果你在 _theme.scss 文件中只写了 @forward "colors"，那么在另一个通过 @use "theme" 引用它的文件里，你依然无法直接使用 $primary-color。因为 theme 模块自身并没有定义这个变量，也没有显式地将其暴露给外界。

要让外部能够访问，必须明确指定暴露方式：

• @forward "colors" as *; → 外部通过 @use "theme" as * 可以直接使用 $primary-color。
• @forward "colors" as color-*; → 外部使用时需要加上前缀，写成 color-primary-color。
• 如果只想转发部分成员，就必须使用 with 子句显式声明：@forward "spacing" with ($spacing-md as $s-md);。

多个 @forward 转发同名变量为什么会报错？

Sass 编译器在命名冲突上非常严格。假设两个不同的子模块都定义并转发了名为 $radius-sm 的变量，即使它们的值完全相同，Sass 也会毫不留情地抛出 "name is already used" 错误。

这种情况在构建工具包入口文件时尤为常见：

• 在 index.scss 中同时 @forward "utils/spacing" 和 @forward "components/card"，而这两个模块恰好都定义并转发了 $radius-sm。
• 使用 show 精确控制暴露的成员时，如果忘记重命名，也会导致冲突：@forward "a" show $radius-sm; @forward "b" show $radius-sm;。

解决冲突的方案通常只有两种：要么在基础层统一提供这个变量，要么在转发时就用 with 进行重命名，例如：@forward "a" with ($radius-sm as $a-radius); @forward "b" with ($radius-sm as $b-radius);。

如何让组件库同时支持 @use "kit" 和 @use "kit" as *？

这无法通过单一的 @forward 实现。一个成熟的组件库入口文件（比如 index.scss）需要巧妙地组合使用 @use 和 @forward。

@use "base/variables" as base;
@use "utils/mixins" as utils;

@forward "base/variables" as base-*;
@forward "utils/mixins" as utils-*;

通过这种结构：

• 希望使用命名空间的用户可以写 @use "index" as i;，然后通过 i.base-primary-color 来访问变量。
• 希望通配导入的用户可以写 @use "index" as *;，然后直接使用 $primary-color 和 @include text-truncate。
• 这里的关键点是：入口文件本身不应该定义任何新的变量或 mixin。所有业务逻辑都应下沉到子模块中，否则转发规则会变得难以预测和控制。

还有一个极易被忽略的细节：当转发函数时，使用 with 进行的重命名只影响函数对外的调用签名，而不会影响函数内部对其他未转发成员的依赖。例如，你将 color.scale-lightness() 转发为 lighten-color()，但如果这个函数内部使用了另一个未被转发的变量 $colors，那么调用时依然会报 Undefined variable 错误。解决方法是，要么补上对 $colors 的转发（如 @forward "colors" as *;），要么在 with 子句中明确将其一并转发（如 with ($colors as $colors)）。