SCSS运算在编译期完成，不支持运行时计算；单位必须一致才能运算，混合单位报错；响应式换算宜用封装函数；涉及CSS变量或动态场景必须用calc()。
先说一个核心概念：SCSS本身并不执行运行时计算。它所有的算术运算，都在代码编译成CSS的那一刻就完成了。我们常说的“动态”效果，其实是依靠变量、运算符和条件逻辑，在构建阶段生成不同的CSS规则。真正到了浏览器里，能让布局随着交互或视口“动”起来的，还得是calc()或者CSS自定义属性这类原生能力。
SCSS 中加减乘除运算符的单位处理规则
SCSS对单位的处理规则堪称“铁面无私”：只有相同单位才能直接进行运算。像20px + 5%这种混合单位的写法，会直接导致编译报错。这并非设计缺陷，而是强制开发者明确自己的设计意图，避免产生模糊不清的样式。
- ✅ 合法操作：
20px + 10px、100px * 2、math.div(40px, 2) - ❌ 会报错：
20px + 5%、1rem - 2px（根本原因在于单位不兼容） - ⚠️ 特别提醒：在旧版Sass中，像
$gap / 2这样的表达式可能会被误解析为CSS除法符号。更安全的做法是显式使用math.div($gap, 2)（要求Sass版本≥1.3），或者用括号包裹起来：($gap / 2)。
响应式布局中 px/vw/vh 的安全换算方式
在做响应式布局时，我们常需要将设计稿的像素值转换为视口单位。但直接手写100vw / 375 * 20这样的表达式，既容易出错，也难于维护。
- 更可靠的方式是封装一个函数：
@function px-to-vw($px, $base: 375px) { @return ($px / $base) * 100vw; } .header { width: px-to-vw(375px); } // 编译结果 → width: 100vw; - 这里有个细节需要注意：
100vw在iOS Safari中可能会包含滚动条的宽度。如果需求是精确占满可视区域，可以考虑使用100dvw，当然，前提是得检查目标浏览器的支持情况。 - 另外，如果项目已经接入了
postcss-pxtorem这类后处理工具，就应避免在Sass层再做一次rem换算（例如14px / 16px * 1rem）。双重转换很容易导致最终的字号出现意料之外的偏差。
何时必须用 calc()，而不是 Sass 运算
那么，界限在哪里？一个简单的判断原则是：只要布局效果依赖于浏览器运行时的状态，Sass的静态计算就无能为力了。具体来说，当涉及CSS变量、用户缩放、滚动状态或视口实时变化时，必须将计算逻辑交给浏览器。
立即学习“前端免费学习笔记（深入）”；
- ✅ 必须用
calc()的场景：height: calc(100vh - var(--header-height) - 60px)（其中--header-height可能由Ja vaScript动态设置）。 - ✅ 必须用
calc()的场景：left: calc((100% - var(--card-width)) / 2)（卡片宽度需要随屏幕尺寸自适应变化）。 - ❌ 不要用Sass替代的场景：
width: #{$card-width / 2}—— 这种插值写法只会输出一个固定的计算值，无法响应其容器尺寸的任何后续变化。 - 一个小技巧：Sass可以用来辅助生成包含
calc()的规则，例如通过插值：margin: calc(#{math.div($gap, 2)} - 1px)。但需要明确，核心的计算工作依然是由浏览器在运行时完成的。
最后，必须警惕一个常见的认知误区：Sass运算的结果是纯粹的、静态的CSS值，它无法感知DOM结构或用户交互行为。真正意义上的“动态”布局，其基石永远是calc()、clamp()或Ja vaScript的配合。别指望仅凭一个@for循环或者math.div()函数调用，就能替代运行时的动态逻辑。这才是关键所在。
