@forward是唯一能实现模块化CSS架构的机制，因@use不支持导出、@import存在编译缺陷；它仅控制对外可见性，不引入变量到当前作用域，需配合@use使用，且同名变量转发会报错以保障命名安全。
因为单独用 @use 无法暴露统一入口，而 @import 会重复编译、变量覆盖、样式爆炸；@forward 是唯一能“只开门、不搬货”的机制，配合 @use 才能实现模块边界清晰、依赖可控、命名可隔离的大型 CSS 架构。
为什么不能只靠 @use 暴露整套工具？
@use 只把模块内容加载进当前作用域，不提供对外导出能力。比如你在 _index.scss 里写：
@use "core/variables"; @use "utils/mixins";
外部 @use "index" 后，什么都访问不到——@use 不转发、不暴露、不中转。
- 想让别人用到
$primary-color，你得额外加@forward "core/variables" as *; - 想保留命名空间（如
v.$primary-color），就得写@forward "core/variables" as v-*; - 所有
@forward必须放在文件最顶部，前面不能有空行或注释，否则报错
@forward 转发后本文件为啥还用不了变量？
常见错误：@forward "tokens" 后直接写 color: $color-primary;，编译报 Undefined variable "$color-primary"。
立即学习“前端免费学习笔记（深入）”；
这不是路径问题，是根本混淆了语义：@forward 只控制“别人能不能看到”，不把变量拉进当前作用域。
- 要在本文件使用变量，必须补一句
@use "tokens" as t;（且@use写在@forward之后） - 转发语句本身不执行任何逻辑，也不触发子模块的顶层 CSS 输出
- 如果被转发的文件（如
_buttons.scss）里写了.btn { padding: 8px; }，这些规则仍会被编译进最终 CSS ——@forward不屏蔽样式，只管声明可见性
多个模块都定义 $radius-sm，@forward 会冲突吗？
会，而且 Sass 会直接报错："$radius-sm" is already used。这不是 bug，是保护机制。
典型场景：同时 @forward "buttons" 和 @forward "cards"，两者都导出了同名变量。
- 安全解法一：统一由基础层（如
_foundations.scss）定义$radius-sm，其他模块只@use不@forward - 安全解法二：用
as隔离命名空间，例如@forward "buttons" as btn-*;→ 外部用btn-$radius-sm - 慎用
with改名：@forward "buttons" with ($radius-sm as $btn-radius)可行，但若该变量被模块内函数引用，而函数依赖未一并重映射的其他变量，仍会报Undefined function
真正难的不是写对第一行 @forward，而是确保每个新增组件都严格走“子模块定义 → 入口 @use + @forward → 样式下沉 → 分层变量”这条链路。漏一次，模块边界就从代码里消失，变成靠人肉记忆维系的脆弱约定。
