dart sass 并未出错,而是将合法 css 原样输出;node-sass 因解析器缺陷把 calc() 中的 / 当作 sass 除法导致报错或错误计算,且不支持 @container、color-mix() 等现代语法,而 dart sass 交由标准 css parser 处理,严格遵循规范透出。

迁移后 CSS 结果变了,不是编译器“出错了”,而是 node-sass(LibSass)原本就在悄悄改你的代码——Dart Sass 只是把真实、合法的 CSS 原样输出了。
calc()、color-mix() 等现代 CSS 函数直接编译失败?
这是最典型的“结果变了”的假象:你写的 calc(100% / 3) 在 node-sass 里根本没被当 CSS 解析,而是被当成 Sass 除法运算,报错中断;Dart Sass 则识别它是原生 CSS 函数,不碰它、不解析、不报错,直接透出到最终 CSS 中。
-
node-sass把/全局当除法符号,calc(100% / 3)→ 解析失败,或错误计算成33.333 - Dart Sass 将
calc()交给标准 CSS parser 处理,width: calc(100% / 3);→ 输出完全一致的 CSS 字符串 - 同理:
@container、color-mix(in srgb, red 50%, blue)、hwb(200 30% 40%)在node-sass中均无法通过词法解析
@import 变量突然 undefined,@use 后样式顺序乱了?
这不是 Dart Sass “变严格”,而是模块系统生效了:@import 是全局污染式加载,@use 是作用域隔离式导入。变量不再自动注入全局,选择器也不再按文件顺序拼接。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1),免gas,支持macOS/Linux/Windows。触发词:/r
- 旧写法
@import "variables"→ 所有变量(如$primary)直接可用;迁移后若没改@use,就真找不到 - 新写法
@use "variables" as v→ 必须显式写v.$primary,否则报Undefined variable -
@use的加载顺序不影响 CSS 输出顺序,但@import的顺序决定!default覆盖和 mixin 展开时机,所以“样式顺序变了”其实是原来就靠巧合生效
::v-deep /deep/ 编译报错,穿透失效?
深度选择器语法本身已被 CSS 规范废弃。node-sass 容忍非标准写法,Dart Sass 按规范校验,空格、伪元素标识都必须精确。
-
/deep/ .btn→ Dart Sass 当作非法选择器,报SassError: expected selector -
::v-deep .btn→ 正确,但注意::v-deep是伪元素,后面必须有空格,写成::v-deep.btn会变成伪类名解析失败 -
/deep/和>>>已从所有现代构建链路中移除,无法通过 loader 回退兼容
includePaths 导致编译慢、路径解析错乱?
看似只是配置项,但它会改变整个模块查找行为:Dart Sass 对 includePaths: ["node_modules"] 的处理是递归扫描,而 node-sass 往往跳过或缓存更激进。
- 路径写成
@use "bootstrap"且includePaths包含node_modules→ Dart Sass 会遍历整个node_modules查找匹配目录,I/O 开销极大 - Windows 下反斜杠路径(
\styles\_mixins.scss)会被 Dart Sass 拒绝,node-sass可能侥幸通过 - CRLF 行尾符在嵌套 map 或多行注释末尾,可能让 Dart Sass 解析中断,
node-sass却“吞掉”了异常
真正容易被忽略的是:你看到的“CSS 结果变了”,90% 是因为 node-sass 曾经用错误方式掩盖了语法问题,而 Dart Sass 把本该暴露的问题,在构建阶段就还给了你——不是它变了,是你第一次看见了代码本来的样子。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










