scss 和 sass 编译出的 css 字节级等价，差异仅在源码语法：scss 是 css 超集，兼容原生 css；sass 依赖严格缩进、禁用符号，易出错且生态支持弱，新版 dart sass 进一步收敛其特性。
SCSS 和 Sass 语法生成的 CSS 完全一致
只要逻辑相同、变量和嵌套结构一致，scss 文件和 sass 文件编译出的最终 CSS 字节级等价。差异只存在于源码书写形式，不体现在输出结果上。编译器（如 Dart Sass）在解析阶段就将两种语法统一转为抽象语法树（AST），后续处理路径完全相同。
缩进语法（.sass）不支持大括号和分号，易因空格出错
这是最常踩坑的地方：.sass 文件依赖严格的缩进层级，且禁止使用 {}、;、:。例如声明颜色变量时：
$primary-color: #3498db
必须写成（注意冒号后必须有空格）：
$primary-color: #3498db
但若写成 $primary-color:#3498db（冒号紧贴），或缩进不一致（比如混用 Tab 和空格），就会报错 Invalid CSS after "...color:#3498db": expected newline, was ""。而 SCSS 允许自由换行、加不加分号、是否缩进都不影响解析。
- 所有属性值必须顶格对齐，子级规则靠缩进表示嵌套
- 不能写
@import "file.scss"这类带引号的路径——得写成@import file（无引号、无扩展名） - 混合宏（
@mixin）和继承（@extend）的调用语法也省略括号，如+centered而非@include centered()
SCSS 是 CSS 超集，可直接粘贴 CSS 代码
这是实际开发中最实用的特性：你把一段现成的 CSS 复制进 .scss 文件，它大概率能直接编译通过；但同样的代码放进 .sass 文件会立刻报错。比如：
.btn {
display: inline-block;
margin: 0.5rem;
}
这段在 SCSS 中合法，在 Sass 语法中必须改写为：
.btn display: inline-block margin: 0.5rem
这意味着：
- 团队协作中引入第三方 CSS 片段（如重置样式、工具类）时，SCSS 成本更低
- 老项目渐进式迁移到 Sass 生态时，
.scss后缀更友好 - VS Code 插件、Lint 工具、CSS-in-JS 互操作等周边生态，几乎全部默认适配 SCSS 语法
Dart Sass 已弃用 .sass 文件的某些旧特性
新版 Dart Sass（v2+）对 .sass 语法做了收敛，部分旧写法不再支持：
-
=声明变量（如$color = red）已被移除，仅支持: - 省略
@include关键字的简写（如+mixin-name）仍可用，但要求 mixin 必须已定义，且不能带参数（带参必须显式写@include mixin-name($arg)） -
@function返回值若为 map，.sass 中访问需用map-get($map key)形式，不能用$map(key)（后者仅 SCSS 支持）
这些限制让 .sass 的“简洁”代价变高——表面少打了几个字符，实则增加了记忆负担和迁移成本。
真正需要关注的不是语法选型，而是团队能否统一缩进风格、是否有人坚持用 Tab 而不是空格、有没有人把 .sass 当作“更高级”的写法去强行改造现有 SCSS 项目。这些隐性摩擦，比语法本身更影响产出质量。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
