SASS在大型项目中是刚需而非锦上添花，因其通过$variables、@mixin、@extend和嵌套提供CSS必需的抽象能力，解决纯CSS维护成本指数级上升问题。
为什么SASS在大型项目里不是“锦上添花”，而是刚需
纯CSS写到几千行后，维护成本会指数级上升——变量散落各处、相同逻辑重复写、改一个颜色要grep全项目、响应式断点硬编码。SASS提供的$variables、@mixin、@extend和嵌套规则，本质是给CSS加了一层可控的抽象能力，不是为了炫技，而是让样式能像JS一样被模块化、复用和测试。
怎么组织SASS文件结构才不翻车
常见错误是把所有样式塞进一个main.scss，或者盲目套用“7-1 pattern”却忽略团队实际协作节奏。关键不是结构多漂亮，而是让修改者能3秒内定位到目标样式。
- 按功能域拆分，比如
_buttons.scss、_grid.scss、_theme-dark.scss，而不是按组件层级（避免_header/_nav/_logo.scss这种过度细分） - 全局变量统一放在
_settings.scss，但只放真正跨模块共享的：如$spacing-xs、$color-primary；组件私有变量留在自己文件里 - 禁止在
@import中使用相对路径别名（如@import "base/typography"），Webpack/Vite对SASS的@import不解析别名，要用~或配置includePaths - 用
@use替代@import（Dart-SASS 1.23+），它默认启用模块作用域，避免变量冲突，但要注意@use不支持循环依赖
嵌套写法看着爽，但什么情况下必须收手
SASS嵌套能减少重复选择器，但超过3层就容易失控——生成的选择器过长、权重爆炸、调试困难，还可能触发浏览器的CSS规则数限制（尤其IE11）。
- 嵌套只用于视觉父子关系明确的场景，比如
.card { &__title { } &__body { } }；不要为“逻辑分组”而嵌套（如把所有按钮状态都塞进.btn里） - 媒体查询嵌套必须用
@media直接写，别用&拼接：@media (min-width: 768px) { .btn { ... } }✅，.btn { @media (min-width: 768px) { &--large { ... } } }❌（生成冗余选择器） - 伪类/伪元素优先用
&:hover，但&::before这类需谨慎——如果父选择器本身已很长（如.layout-main .sidebar .nav-item），再加::before会让最终选择器难以覆盖
编译后CSS体积暴增？检查这三件事
很多人发现用了SASS反而打包体积变大，问题往往不在预处理器本身，而在开发习惯。
立即学习“前端免费学习笔记（深入）”；
-
@extend滥用：它会把被扩展的选择器完整复制到每个使用处，@extend .clearfix在10个地方用，就复制10次；改用@mixin clearfix()+@include更可控 - 未开启压缩：Dart-SASS默认不压缩，构建时必须加
--style=compressed参数，否则保留空格、注释、换行，体积翻倍不止 - source map未关掉生产环境：开发时开
sourceMap: true没问题，但上线前务必关闭，否则.css.map文件可能比CSS本身还大
最常被忽略的一点：SASS本身不解决CSS作用域问题。即便用了@use和模块化，最终输出仍是全局CSS。大型项目真要隔离样式，得配合CSS Modules、CSS-in-JS，或者用:scope和自定义属性做运行时控制——SASS只是帮你把混乱写得更整齐，不是自动给你上锁。
