!global会破坏@use的作用域隔离，将变量强行注入全局命名空间，导致不可预测的覆盖与调试困难；应优先使用@forward、CSS自定义属性或预处理器配置替代，仅在兼容遗留@import时严格受限使用。
直接结论：在 Sass 中使用 !global 是主动放弃作用域控制的危险操作，它会绕过 @use 的隔离机制，把变量强行写入全局命名空间——这不是“解决污染”，而是制造污染。真正要做的不是怎么用好 !global，而是理解它为何不该出现在模块化项目中。
为什么 !global 会破坏 @use 的作用域隔离
@use 的核心价值在于默认私有：所有变量、混入、函数都只在当前模块内可见，除非显式通过 as * 或命名空间暴露。而 !global 直接穿透这层隔离，把本该局部的变量“钉”进全局作用域，导致后续任何 @use 或 @import 都可能意外覆盖或读取到它。
常见错误现象：
— 某个组件内部用 $z-index-modal: 1000 !global;，结果另一个完全不相关的下拉菜单弹出层级被顶高
— 多个文件先后执行 $theme: 'dark' !global;，最终值取决于编译顺序，无法预测
-
!global不受文件加载顺序影响，但受编译时执行顺序影响——Sass 不保证模块执行顺序，尤其在并行构建中 - 一旦某个变量被声明为
!global，后续同名变量无论是否加!global都会覆盖它（Sass 规则） - VS Code 或 WebStorm 的 Sass 语言服务通常无法正确跳转或提示
!global变量来源，调试成本陡增
哪些场景看似需要 !global，其实有更安全的替代方案
开发者常以为“主题切换”“运行时配置注入”必须靠 !global，其实不然。Sass 编译期不支持真正的运行时变量，所谓“动态主题”本质是多入口编译或 CSS 自定义属性桥接。
- 想让多个独立模块共享一套颜色配置？→ 用
@forward "variables" show $primary-color, $font-size-base，由统一入口控制暴露范围 - Vue/React 组件中想根据 props 切换样式？→ 改用 CSS 自定义属性（
--primary-color），Sass 只负责生成初始值，运行时交由 JS 控制 - Vite 项目里想全局可用变量？→ 配置
css.preprocessorOptions.scss.additionalData，用@use "@/styles/variables.scss" as *注入，而非在每个文件里写!global - 旧项目迁移时发现大量
!global？→ 先全局搜索!global，逐个评估：能否改为模块内局部变量？能否上提至@forward入口？能否替换为 CSS 自定义属性？
!global 唯一勉强合理的使用场景及严格限制
仅当你要与遗留的、无法修改的 @import 代码共存，且必须让新模块“向后兼容”旧全局变量时，才考虑极小范围使用。即便如此，也必须满足以下全部条件：
- 只在项目最顶层的入口文件（如
main.scss）中声明，绝不放在组件或工具模块里 - 变量名必须带明确前缀，如
$legacy-grid-columns !global;，避免与未来模块变量冲突 - 声明后立即加注释说明用途、生命周期和移除计划，例如：
// TODO: 移除于 v2.0，届时改用 @forward "grid" show $columns - CI 流程中加入正则检查（
/!global.*;/g），禁止新增!global提交
真正容易被忽略的点是：Sass 模块化不是语法升级，而是协作契约。当你写下 !global，你就在单方面撕毁这个契约——它不会报错，但会在几个月后让新同事在凌晨三点对着一个莫名其妙的 $spacing-xs 值抓狂。克制比技巧更重要。
