Sass变量命名应以可维护性优先，采用$color-blue-500、$space-md等带层级和单位的格式；嵌套不超过三层，超层用BEM平铺；mixins所有非核心参数须设默认值；全项目统一使用@use，禁用@import混用。
如何为Sass变量命名才能确保长期可维护性
为Sass变量命名，其核心目标并非追求绝对的语义化，而是要解决一个更实际的开发痛点：确保数月后回顾代码时，你能迅速判断$button-primary-bg与$blue-500哪个是局部样式变量，哪个是全局设计令牌，避免因误改引发连锁问题。
- 基础设计值必须包含层级与单位。对于颜色、间距、圆角等全局基础设计值，务必采用
$color-blue-500、$space-md这类结构化命名。应避免使用$main-blue等模糊词汇，因为“main”的定义会随项目迭代而模糊，导致后续维护困难。 - 组件变量必须严格隔离作用域。仅属于特定组件的变量，例如以
$btn-开头的变量，应严格限定在对应的_button.scss模块文件中。切勿为图方便而用$btn-height去控制input元素的高度，视觉上的巧合并非逻辑关联，强行复用会为项目埋下技术债务。 - 命名应与具体状态解耦。尽量避免
$dark-mode-text这类直接绑定特定模式（如深色主题）的变量。更优的做法是使用$text-color-primary这类功能性命名，然后通过上下文选择器（如body[data-theme="dark"]）来切换其具体值。否则，每新增一个主题下的组件，都需要补充大量状态变量，极大降低代码可扩展性。
Sass嵌套层级应控制在多少层以内
Sass嵌套的层级深度并非简单的代码风格问题，而是直接影响CSS输出权重与样式耦合度的关键。嵌套超过三层会导致编译后的选择器特异性过高，更严重的是，会使样式与DOM结构深度绑定。你可能仅删除一个父容器，就导致子组件样式全面崩溃——这种“删除一行代码，整个表单按钮变透明”的诡异问题，在真实调试中确实会发生。
- 结构嵌套建议以两层为限。对于纯粹的DOM结构嵌套（例如
.card > .card__header > h3），最多允许嵌套两层。从第三层开始，应放弃继续嵌套，转而采用BEM方法论，使用独立的类名（如.card__title）进行扁平化书写。 - 伪类与媒体查询应视为独立层级。
&:hover、&:focus等伪类，以及@media媒体查询规则本身应计为一个层级，其内部不建议再嵌套其他复杂选择器，以保持规则扁平清晰。 - 善用
@at-root跳出当前嵌套上下文。当某个样式需要跳出当前嵌套作用域时，主动使用@at-root指令比强行嵌套更为安全清晰。例如，在.modal内部需要重置body元素的滚动行为，直接书写@at-root body { overflow: hidden; }，远比在.modal__overlay &中绕行逻辑要易于理解和维护。
在Sass mixins中哪些参数必须设置默认值
一个未设置默认值的mixin参数，几乎等同于一个潜在的运行时错误。设想你调用@mixin flex-center($direction)时遗漏了参数，编译器只会抛出Undefined variable "$direction"的错误，且报错位置指向调用@include的那行代码，这使你难以快速定位问题根源在于mixin定义本身缺少了默认值。
- 所有非核心功能参数必须提供默认值。对于不影响mixin核心功能的配置项参数，必须设置合理的默认值。例如：
@mixin button($variant: 'primary', $size: 'md', $full-width: false)。 - 颜色参数应谨慎使用
null作为默认值。将颜色参数默认值设为null（如$color: null）会导致后续的条件判断if ($color) {...}始终为假。更符合CSS原生行为的做法是使用inherit、transparent或currentColor等值作为默认值。 - 保持参数类型灵活性，避免过度限制。对于接收CSS属性值的参数（如
$padding、$margin），不应强制限定其类型。应允许传入长度单位（如1rem）、CSS自定义属性（如var(--space-lg)）甚至计算表达式（如calc(1rem + 1px)）。若使用@if type-of($padding) != 'number'进行严格校验，反而会阻碍许多合法且实用的高级用法。
为何混用@import和@use会导致样式突然失效
这是Sass从旧版向模块化系统升级过程中最常见的陷阱之一。@use是现代模块化语法，具有独立的作用域；而@import是旧的全局合并模式。两者混用会引发作用域冲突与变量覆盖问题：通过@use引入的变量和mixin，在通过@import加载的文件中不可见；反之，@import文件中用!default标记的变量，可能会无声地覆盖@use模块中的声明。最终表现就是样式随机丢失，或页面呈现的色彩与布局混乱不堪，排查难度极大。
- 全项目统一使用
@use语法。这是根本的解决方案。将旧的_variables.scss等文件通过@use "variables" as v;方式引入，调用时使用带命名空间的前缀，如v.$color-primary。 - 兼容第三方库可使用
@forward进行封装转发。如果使用的第三方Sass库（如Bootstrap的Sass版本）尚未提供对@use的原生支持，可以创建一个中间封装文件，使用@forward规则将其内部文件转发出去，然后再通过@use引入这个封装层。例如：先@forward "bootstrap/scss/functions";，再@use "bootstrap" as bs;。 - 绝对禁止在
@use之后使用@import。即使你仅想用@import引入一个字体文件或重置样式，也必须避免。Sass会将@import的内容注入到@use模块作用域之外，这会立即导致模块内的变量引用失效，破坏整个模块系统。
总而言之，变量命名规范与嵌套层级限制尚可写入团队编码规范文档，但@use与@import的加载顺序、模块作用域的隐形边界等细节，才是真正考验开发者功底、容易导致项目上线前彻夜排查的关键所在。掌握这些Sass高级技巧与最佳实践，能显著提升大型项目的样式代码可维护性与团队协作效率。
