Sass 这个名称实际包含两套语法：以缩进为核心的 .sass 语法和以花括号为核心的 .scss 语法。两者共享同一套预处理器核心，变量、嵌套、混入、继承和函数等能力完全一致，但在书写体验和兼容性上存在差异。
一、Sass与SCSS的历史定位
Sass 最初是 Ruby 社区推出的 CSS 预处理器，最早版本受到 Haml 模板语言影响，使用严格的缩进表示层级关系。这种语法文件扩展名为 .sass，属性之间用换行分隔，不需要写分号和花括号。由于缩进语法与大家熟悉的 CSS 写法差异较大，当时不少前端开发者并不容易接受。为了让迁移成本更低，Sass 3 版本引入了 SCSS 语法，全称是 Sassy CSS，文件扩展名为 .scss。SCSS 完全兼容 CSS3 标准，任何合法的 CSS 样式块都可以直接放进 .scss 文件里使用。也就是说，Sass 并不是两个不同的工具，而是同一个预处理器提供了两种书写风格。开发者可以根据团队规范和个人偏好选择其中一种，甚至可以借助编译工具在两者之间互相转换。
从编译器的角度看，.sass 和 .scss 最终都会经过相同的 Sass 引擎处理，生成标准的 CSS 文件。变量、嵌套规则、混合宏、函数、继承等核心特性在两种语法下都完整存在，只是表达方式不同。例如 SCSS 用 $primary: #42a5f5; 声明变量，而缩进语法同样使用 $primary: #42a5f5 但没有分号。理解这一点有助于消除一个常见误区：认为 .sass 是旧版、.scss 是新版，或者把两者当成不同的预处理器。实际上它们只是同一套能力的不同入口。
二、语法层面的核心差异
最直观的区别当然是符号。SCSS 使用花括号包裹声明块，使用分号结束每一条声明；.sass 语法则把这些符号全部省略，依靠缩进和换行来识别结构。以下代码分别展示同一个按钮样式的两种写法。
$primary: #42a5f5;
.btn {
display: inline-block;
padding: 8px 16px;
color: $primary;
&:hover {
color: darken($primary, 10%);
}
}
$primary: #42a5f5
.btn
display: inline-block
padding: 8px 16px
color: $primary
&:hover
color: darken($primary, 10%)
可以看到，SCSS 版本更接近原生 CSS，熟悉 CSS 的开发者基本可以无缝上手。.sass 版本去掉了花括号和分号，代码量略微减少，视觉上更干净。嵌套关系通过缩进表达时，层级越深缩进越明显，这就要求团队必须统一使用空格或 Tab，并且缩进宽度保持一致。一旦混用空格和 Tab，编译器可能直接报错，甚至产生错误的嵌套结构。
除了基础嵌套，两者在混合宏、函数和流程控制上的写法也有差异。比如 SCSS 定义一个混合宏使用 @mixin rounded($radius) { ... }，调用时用 @include rounded(4px);；.sass 中则写成 @mixin rounded($radius) 后换行缩进，调用时写 @include rounded(4px) 不带分号。变量插值、颜色函数、运算等功能行为完全一致，只是语句结尾是否需要分号的区别。因此，学习 Sass 的核心能力并不需要重复掌握两套知识，只要理解符号差异即可快速切换。
三、文件扩展名与编译转换
文件后缀是区分两种语法的主要标识。.scss 文件必须使用 SCSS 语法，.sass 文件必须使用缩进语法。如果只是把 .scss 文件直接改名为 .sass，编译器会按照缩进语法进行解析，原有的花括号和分号就会变成非法字符，导致编译失败。反过来把 .sass 改名成 .scss 同样会报错，因为缺少分号和花括号无法被 SCSS 解析器识别。因此，修改后缀必须配合语法调整，不能单独改名。
官方提供了 sass-convert 命令行工具，可以自动完成两种语法之间的转换。例如要将一个 SCSS 文件转换为缩进语法，可以执行 sass-convert input.scss output.sass；反向转换可以执行 sass-convert input.sass output.scss。在现代前端构建流程中，Vite、Webpack、Gulp 等工具通常通过 sass 或 dart-sass 编译器自动根据扩展名选择解析方式，并且可以同时处理两种文件。项目里也允许混合使用 .scss 和 .sass 文件，通过 @use 或 @import 引入时编译器会按照对应后缀解析。不过为了减少维护成本，大部分团队会统一为一种语法。
四、实际项目中的选择建议
如果是新项目，并且团队成员主要来自原生 CSS 背景，SCSS 几乎是不需要思考的选择。因为 SCSS 完全兼容 CSS，旧样式代码可以直接粘贴进来，逐步添加变量、嵌套和混合宏。Code review 时，花括号和分号的显式结构也更容易对照检查，降低因缩进错误带来的隐性风险。对于需要快速上手的实习生或初级开发者，SCSS 的学习曲线明显更平缓。
.sass 缩进语法则更适合追求代码简洁性的小团队或个人项目。省略花括号和分号之后，文件通常会更短，尤其是在深度嵌套的组件样式中，视觉噪音较少。但它对缩进纪律要求很高，编辑器的自动格式化配置必须统一，否则多人协作时容易出现空格和 Tab 混用导致的编译异常。此外，有些 CSS 相关工具或插件对 .sass 的支持不如 .scss 完善，比如复制代码片段到 CSS 工具中调试时会稍显麻烦。
无论选择哪种语法，核心变量体系、模块化拆分和函数封装思路是一致的。如果后期需要迁移，也可以借助 sass-convert 工具批量完成。建议在项目文档中明确约定统一的语法后缀和缩进规则，避免因为个人偏好造成代码库风格混乱。Sass 与 SCSS 的本质区别是语法表达，而不是能力边界，选择适合团队的方案比争论哪种语法更好更有价值。
