scss模块化通过@use实现命名空间引用，解决变量冲突与隐式覆盖问题，强制声明依赖并剔除未用代码，需配合合理目录结构与导入顺序才能避免全局污染。
因为模块化不是让文件变多，而是让依赖可追溯、变量不打架、样式不越界——没有它，NES.css这类框架根本没法按需引入按钮或像素画组件。
SCSS模块化如何防止变量冲突
原生CSS的--primary-color在@media里不能参与lighten()计算，而SCSS的$primary-color是编译期常量，能用在任何逻辑里。但变量不会自动跨文件生效：
- 写
$spacing-xs: 4px在_button.scss里，其他文件@import后依然报Undefined variable - 旧式
@import会把所有变量塞进全局作用域，某个组件意外重定义$border-radius，整个主题就崩 - Dart Sass 2.0+必须用
@use 'abstracts/variables' as vars，调用时显式写vars.$spacing-xs，杜绝隐式覆盖
@use比@import真正解决什么问题
@import是“把内容复制粘贴进来”，@use是“建立命名空间引用”。区别直接体现在维护性上：
- 同一变量
vars.$spacing-sm可在_buttons.scss和_forms.scss中各自使用，互不干扰 - 未使用的变量和
@mixin会被编译器自动剔除，CSS体积更小 -
@use强制你声明依赖，比如@use 'layout/grid' as grid，谁用了栅格、谁没用，一眼可见
模块划分不当会直接污染布局层
很多人把layout/当成“所有盒子模型”的垃圾桶，结果塞进_header.scss、_modal.scss——这已经越界到组件层了：
-
layout/只该放_grid.scss（栅格系统）、_container.scss（容器宽度与居中）、_flex.scss（@mixin flex-row()等），不含任何视觉语义 - 页头、弹窗、侧边栏这些有明确交互行为的，必须归入
components/或sections/ - 一旦布局层混入组件逻辑，
@include grid.make-columns()就可能被误用于按钮内部，破坏抽象边界
局部文件（partials）不是为拆而拆
以_button.scss为例，它必须包含：$button-padding变量、@mixin button-variant()、%button-reset占位符、以及.btn规则本身——否则_dropdown.scss就无法安全@extend %button-reset：
- 文件名带下划线（
_button.scss）确保不会被Webpack/Vite误编译成独立CSS - 禁止在
main.scss中直接@import 'button'，必须走统一入口@import 'core/index'，由core/_index.scss控制加载顺序 -
_variables.scss和_functions.scss必须排在所有组件文件之前，否则@mixin里调用rem-calc(12px)会报错
模块化真正的复杂点不在怎么拆文件，而在变量作用域、导入顺序、命名空间引用这三者的咬合——漏掉任意一环，都可能让@use变成假模块化，表面整洁，实际照样全局污染。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
