SCSS数学运算在编译期完成，不影响浏览器渲染性能；真正需警惕的是可维护性风险，如隐式耦合、单位混用、推导链过长及依赖运行时上下文导致的调试困难。
SCSS 复杂数学运算不会拖慢浏览器渲染
SCSS 的所有数学运算（比如 calc(100vw - 2rem) 以外的表达式）都在编译时完成，不是运行时执行。浏览器最终拿到的是纯 CSS，根本看不到 $base * 1.25 + $gap / 2 这类写法。所谓“影响 CSS 解析性能”是常见误解——解析器只处理生成后的静态值，比如 font-size: 18px，跟它是怎么算出来的毫无关系。
真正该警惕的是编译阶段的可维护性与隐式耦合
复杂运算容易把设计系统逻辑锁死在样式文件里，导致后续调整困难。比如：
-
$spacing-xs被用在margin: $spacing-sm * 0.75、padding: $spacing-lg / 3、border-radius: sqrt($spacing-xl)等多处，一旦改基础值，结果不可预测 - 使用
round()、percentage()或嵌套函数（如lighten(darken($color, 10%), 5%)）会让颜色/尺寸推导链变长，调试时难以反向追踪来源 - 涉及单位混合的运算（如
10px + 2em）在旧版 Sass（Dart Sass 之前）可能触发静默转换或报错，而 Dart Sass 虽支持，但语义已模糊——你真能确定2em是相对于哪个元素计算的？
什么情况下可以放心用 SCSS 数学运算
只要满足「单向、显式、有限层级」三个条件，就属于安全范围：
- 仅用于派生常量：比如
$line-height: 1.5→$line-height-tight: $line-height * 0.9，且只在变量定义区集中声明 - 单位一致：全用
px或全用rem，避免混用；若需响应式缩放，优先用clamp()或媒体查询，而非在 SCSS 里写min(16px, 4vw)（后者不合法，Sass 不支持 CSS 函数内联） - 不依赖运行时上下文：比如不要基于
container-width做运算（SCSS 没有容器查询上下文），也不要试图用@function模拟 JS 式动态逻辑
Dart Sass 的实际性能瓶颈不在数学运算本身
真实慢点通常来自：
立即学习“前端免费学习笔记（深入）”；
- 大量
@import或@use嵌套（尤其 node_modules 里的大型库） - 自定义函数中递归调用或遍历长列表（如对 50+ 个断点做
@each生成媒体查询） - 未启用缓存（如 Webpack 的
sass-loader缺少implementation: require('sass')配置，退回到较慢的 Node Sass）
一个含 20 处 $a + $b * 2 的文件，和全用字面量的同体积文件，Dart Sass 编译耗时差异通常低于 3ms——远小于 I/O 或 AST 解析开销。
真正难调试的，从来不是 “16px × 1.125 算得对不对”，而是 “这个 18px 到底是从哪一层变量透传过来的，中间被几个 !default 覆盖过”。
