Dart Sass 是当前唯一被官方 actively maintained 的 Sass 实现，Ruby Sass、LibSass 和 Node Sass 均已停更；它由原作者团队开发，独占支持 :has()、color-mix()、@use/@forward 等新特性，且通过 CSS Spec Test Suite 验证兼容性。
Dart Sass 是当前唯一被 Sass 官方团队 actively maintained 的实现，LibSass 已于 2020 年 10 月正式弃用，不再接受新特性、CSS 规范同步或安全之外的任何更新。
为什么 Dart Sass 成为官方标准
这不是一个“选型建议”，而是事实性收敛：Ruby Sass（2019 年停更）、LibSass（2020 年弃用）、Node Sass（随 LibSass 停更）均已退出维护轨道。Dart Sass 由 Sass 原作者团队直接开发，所有新版 CSS 功能（如 :has()、color-mix()、lab()/lch() 颜色函数）都只在 Dart Sass 中第一时间落地。
关键点在于——它不是“更快”或“更轻量”的替代品，而是“唯一能跟上 CSS 演进”的编译器。比如 @use 和 @forward 这套模块系统，从 Sass 1.23.0 起成为强制推荐，LibSass 根本不解析 @use，直接报错 SassError: @use rules must be written before any other rules。
LibSass 对 CSS 特性的支持断层
LibSass 停留在 CSS 2018 年前的语义理解水平，对现代 CSS 的解析存在三类硬性缺失：
立即学习“前端免费学习笔记（深入）”；
- 不识别
env(safe-area-inset-*)等原生环境变量，会当作非法标识符报错 - 无法处理
calc()中混用单位与函数（如calc(1rem + lch(50% 30 200))），而 Dart Sass 可完整解析并参与编译时计算 - 对自定义属性（
--my-var）在@if或@each中的运行时读取完全无支持，只能靠 JS 插件模拟
这些不是“兼容性问题”，是底层 AST 解析器未实现对应语法节点。你改写再多次，LibSass 也不会认识 color-contrast()。
Dart Sass 的 CSS 兼容性验证方式
官方提供 CSS Spec Test Suite，所有 PR 合并前必须通过该测试集。你可以本地验证：
npm install sass
npx sass --version // 输出应为 >=1.70.0（已完整支持 :has()）
echo ':has(.foo) { color: red; }' | npx sass --stdin
如果返回 CSS，说明支持；若报 Invalid selector，说明你实际还在用 node-sass 或旧版 dart-sass。
注意：sass 包名 ≠ node-sass —— 后者早已被 npm 标记为 DEPRECATED，且安装时会明确警告 “Use 'sass' instead”。很多项目里 package.json 还留着 "node-sass": "^6.0.0"，但构建工具（如 Vue CLI 5+、Vite）内部已悄悄 fallback 到 sass，造成行为不一致。
迁移后最易忽略的隐性差异
颜色运算精度、浮点数舍入、@import 循环检测逻辑、甚至注释保留策略，在 Dart Sass 中都和 LibSass 不同。例如：
- LibSass 中
rgba(#ff0, 0.3)输出rgba(255,255,0,0.298)；Dart Sass 输出rgba(255,255,0,0.3) - LibSass 允许
@import "x"; @import "x";（重复导入不报错）；Dart Sass 报Import loop - LibSass 会把
/* comment */压缩进生成 CSS；Dart Sass 默认只保留/*! important */
这些差异不会导致构建失败，但会让视觉回归测试（visual regression test）意外失败——尤其在设计系统中依赖像素级一致性的场景。
