@forward 不向当前作用域注入变量，仅声明对外暴露的成员；命名冲突需通过统一收口或 with 改名解决；as 易致撞名，as prefix- 更安全；入口文件须纯中转，不可定义新成员。
@forward 本身不造成命名空间混乱，混乱来自误用它替代 @use，或在转发时未显式控制成员暴露方式。
为什么 @forward 后变量在当前文件里用不了
这是最常被误解的一点：@forward 不是“把变量搬进来”，而是“告诉外面的人：你通过我这个文件，能访问哪些东西”。它不会向当前作用域注入任何变量、函数或 mixin。
- 写
@forward "colors"，当前文件里依然不能直接用$primary-color—— 必须先@use "colors" as c才能访问c.$primary-color - 想让使用者
@use "theme" as *后直接用$primary-color，得在theme/index.scss里写@forward "colors" as * - 如果
theme/index.scss自己定义了$spacing-md: 16px，但没写@forward这个变量，那它对外完全不可见
如何避免多个 @forward 导致 name is already used 错误
当两个模块都转发了同名成员（比如 $radius-sm），Sass 编译器会报错，这不是 bug，是强制你面对命名冲突。
- 典型场景：
@forward "utils/spacing"和@forward "components/card"都含$radius-sm - 解决路径只有两条：
— 把该变量统一收口到基础层（如core/vars），其他模块只@use不@forward
— 用with显式改名：@forward "utils/spacing" with ($radius-sm as $util-radius-sm) - 别指望“后写的
@forward覆盖前一个”来绕过——这会让下游使用者完全无法预测行为
@forward as * 和 as prefix-* 的实际影响
命名空间是否“干净”，取决于你是否主动控制前缀粒度，而不是靠 as * 图省事。
-
@forward "mixins" as *→ 使用者@use "kit" as *后可直接@include fluid-type()，但所有 mixin 都暴露在全局，易撞名 -
@forward "mixins" as mix-→ 使用者必须写@include mix-fluid-type()，隔离性强，但调用略长 - 混合使用风险高：
@forward "vars" as *+@forward "mixins" as mix-会导致变量无前缀、mixin 有前缀，API 不一致，维护成本陡增
真正容易被忽略的点是：入口文件（如 index.scss）自己不能定义新变量或 mixin。只要加了一行 $tmp: 12px，它就不再是纯中转站，@forward 的转发规则就会失效或产生隐性干扰。模块逻辑必须彻底下沉，否则命名空间从根上就不稳。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
