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 是作用域隔离式导入。变量不再自动注入全局，选择器也不再按文件顺序拼接。
- 旧写法
@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 按规范校验，空格、伪元素标识都必须精确。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
立即学习“前端免费学习笔记（深入）”；
-
/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 把本该暴露的问题，在构建阶段就还给了你——不是它变了，是你第一次看见了代码本来的样子。
