SCSS私有成员命名法（$_或$-前缀）非语法强制，而是依赖@use模块系统的默认不导出规则，确保内部变量、mixin、function不被外部访问，从而保障封装性与可维护性。
私有成员命名法不是语法强制，而是模块系统默认行为
SCSS 本身没有“私有变量”语法，$_color-primary 或 $-helper 这类写法不会触发编译报错，也不会被 Sass 解析器拦截访问。它的“私有性”完全依赖于 @use 模块系统的默认导出规则：所有以 $_ 或 $- 开头的变量、mixin、function，在 @use 加载时**默认不对外暴露**。
这意味着：
- 在
@use "colors"后，colors.$_color-primary是非法访问，编译失败 - 但如果你用
@import "colors"，$_color-primary会直接进入全局作用域，可读可覆盖 - 文件名里的下划线（如
_colors.scss）只影响是否单独编译成 CSS，和变量可见性无关
为什么不用私有命名法会导致下游误用
当一个模块提供工具函数或内部状态变量（比如 $-grid-breakpoint-stack、$_internal-reset-flag），它们本意是供本模块内 @include 或逻辑判断使用，而非供外部调用。一旦不加前缀导出，下游项目就可能：
- 直接写
grid.$-breakpoint-stack并试图修改它，破坏模块封装 - 在多个地方重复依赖同一内部结构，导致升级时无法安全重构
- 把临时调试变量（如
$_debug-mode）当成配置项暴露给主题层，引发不可控副作用
而加了 $_ 前缀后，IDE 和编译器会自然过滤掉这些成员，调用方连代码提示都看不到——这才是最轻量的“隐藏”。
@forward 会意外暴露私有成员吗
会，但只在你主动破坏规则时发生。默认情况下：@forward "colors" 只转发非 $_ 开头的成员；但以下写法会绕过保护：
-
@forward "colors" as *：解构导入，但$_成员依然不会进入当前作用域 -
@forward "colors" show $color-primary, $_color-warning：显式show就等于主动开闸 -
@forward "colors"+ 在同一文件里又写了@use "colors" as internal，再手动@include internal._private-mixin：相当于自己挖洞
真正危险的是漏掉 hide 控制，比如想转发所有公共项但忘了屏蔽几个内部变量：@forward "utils" hide $_cache-map, $-internal-config 才是稳妥做法。
验证私有性最简单的方法就是编译时访问
别靠文档或命名猜，直接试：
- 在另一个文件里写
colors.$_color-primary→ 编译报Undefined variable "$_color-primary"，说明私有生效 - 写
@include colors._reset-helper→ 报Undefined mixin "_reset-helper"，同理 - 但如果在同一个
@use文件里写$_color-primary: blue，完全合法——私有只是“不导出”，不是“不能定义”
最容易被忽略的是：私有性只对 @use 生效，且完全取决于你是否在 @forward 中显式放开。名字带下划线不是魔法，是契约；不遵守契约，契约就失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
