scss是现代前端默认选择，因其语法完全兼容css，改后缀即可编译；sass（.sass）依赖严格缩进、禁用符号，易出错且生态支持弱，dart sass已将其标记为遗留语法。
SCSS 是现代前端事实上的默认选择，不是因为功能更强，而是因为它的语法天然兼容 CSS，而 Sass（.sass）缩进语法在工程中已基本被弃用。
SCSS 文件能直接当作 CSS 文件用
任何合法的 .css 文件，只要改后缀为 .scss，就能被 Dart Sass 正常编译——不需要改一行代码。比如：
/* style.css → 重命名为 style.scss 后仍可直接编译 */
body {
margin: 0;
font-family: sans-serif;
}
这种零迁移成本，让团队可以渐进式引入变量、嵌套、@mixin等特性，而不是一次性重构整套样式。Sass（.sass）做不到这点：它不接受大括号、分号、冒号，哪怕只有一行 color: red;，也会报错 Invalid CSS after "color": expected "{", was ":"。
Sass（.sass）缩进语法极易因空格出错
缩进语法依赖视觉对齐，但实际开发中这些细节极难把控：
- 编辑器自动缩进设置不一致（如 Tab vs 2空格 vs 4空格），会导致编译失败
- 复制粘贴时缩进被破坏，错误提示往往指向“意外缩进”，而非具体哪一行
- Git diff 中缩进变化难以识别，Code Review 几乎无法判断语义是否变更
- IDE 插件支持弱：VS Code 默认不带 .sass 语法高亮，需额外安装且常失效
一个典型错误是：
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
// 错误写法（看似对齐，实则混用了 Tab 和空格）
$primary: #333
body
color: $primary
font-size: 16px
line-height: 1.5 // 这里多了一层缩进，编译器认为它是 font-size 的子属性
结果报错：Invalid indentation: expected a newline or semicolon，但问题根源藏在上一行末尾。
Dart Sass 已明确弱化 .sass 支持
自 Dart Sass 1.3.0 起，官方文档已将 .sass 语法标记为“legacy syntax”，且新版编译器默认禁用部分旧特性（如隐式 @import）。更关键的是：
-
sass --watch对.sass文件的热更新稳定性不如.scss - 主流构建工具（Vite、Webpack、Next.js）的默认 Sass 集成都优先适配
.scss，对.sass需手动配置 loader - 几乎所有 UI 组件库（如 Ant Design、Vuetify）发布的源码都是
.scss，没有提供.sass版本
这意味着：你很难在真实项目中找到除个人玩具项目外的 .sass 实际用例。
两者编译出的 CSS 完全一样，但路径成本差很多
只要逻辑相同，test.scss 和 test.sass 编译出的 CSS 字节级等价——这是 Dart Sass 在 AST 层统一处理的结果。但代价完全不同：
- SCSS：改后缀 + 加个
$color: red;就能跑起来 - Sass：得重写所有规则结构，适应无符号语法，还要说服整个团队接受新缩进规范
真正容易被忽略的一点是：**CSS 兼容性不只是“能编译”，更是“能协作”**。当设计师导出的 style.css 能直接扔进 src/styles/ 并立刻参与构建时，这个“兼容性”才真正落地。而 .sass 从第一步就卡在文件名和格式上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
