Sass 本身不强制模块化，但通过 @use、@forward 和文件命名约定能自然形成清晰层级结构；关键在于文件组织而非语法使用。
直接说结论：Sass 本身不强制模块化，但通过 @use、@forward 和文件命名约定，能自然形成清晰的层级结构；关键不在“怎么写 Sass”，而在“怎么组织文件”。
用 @use 替代 @import 建立明确依赖关系
Sass 官方已弃用 @import，它会全局污染变量和混合宏，导致样式覆盖难追踪。改用 @use 后，每个模块的变量、函数、混合宏默认私有，必须显式暴露或带命名空间调用。
-
@use "base/variables"→ 变量需写成variables.$primary-color -
@use "base/mixins" as m→ 混合宏变成@include m.respond-to("md") - 同一文件多次
@use不重复编译，性能更稳
按功能分层建目录，避免“all-in-one”单文件
典型但易被忽略的结构是把所有样式堆进一个 main.scss。实际应按职责切分，例如：
-
_variables.scss：只放 CSS 自定义属性和基础值（如$spacing-xs: 0.25rem） -
_functions.scss：纯逻辑函数（如strip-unit($value)），不输出 CSS -
_mixins.scss：可复用的行为封装（如@mixin visually-hidden） -
components/_button.scss：组件级样式，只依赖variables和mixins，不引入其他组件
这种分层让修改按钮样式时，不会意外触发表单或布局文件重编译。
立即学习“前端免费学习笔记（深入）”；
用 @forward 聚合公共接口，控制暴露粒度
当多个子模块需要统一入口（比如整个 base 层），用 @forward 封装，而非简单 @use 全部导入：
// base/_index.scss @forward "variables" as var-*; @forward "mixins" as mixin-*; @forward "functions" as fn-*;
-
@use "base" as b后，可用b.var-primary-color、b.mixin-center-absolute -
@forward "mixins" hide respond-to可隐藏某个混合宏，防止误用 - 比手动在主文件里逐个
@use更易维护，也避免下游直接依赖深层路径
嵌套层级别超过 3 层，就该拆出新模块或换选择器策略
Sass 支持深度嵌套，但 .card { .header { h2 { color: $text-dark; } } } 看似简洁，实则带来三个问题：
- 生成的选择器过长（
.card .header h2），CSS 特异性高，后期难覆盖 - HTML 结构一变，样式全失效，违背“样式与结构解耦”原则
- IDE 很难跳转到
h2对应的样式块，因为它是嵌套在多层大括号里的
更稳妥的做法是：用 BEM 命名 + 单层 @use 导入，例如 .card__title 直接写样式，不依赖父选择器嵌套。
真正难的不是写嵌套或用 @use，而是判断“这个变量该放在哪一层”“这个混合宏是否已过度抽象”——这些决策没有语法报错，但会在半年后重构时集中爆发。
