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反而打包体积变大，问题往往不在预处理器本身，而在开发习惯。 Zeemo AI 一款专业的视频字幕制作和视频处理工具