SCSS算术运算仅在编译期执行，输出静态CSS值，无法响应屏幕变化；单位必须一致（如px与rem不可混算），需通过函数统一转换或交由calc()等运行时机制处理。
SCSS运算只能在编译期算出固定值，别指望它响应屏幕变化
SCSS 的 +、-、*、/ 全部发生在构建阶段，输出的是静态 CSS。比如 $gap: 20px; margin: $gap * 1.5; 编译后就是 margin: 30px; —— 它不会随视口缩放、不会随用户字体设置变化、也不能被 JS 修改。真要“动态”，必须交由浏览器运行时处理，SCSS 只能帮你准备比例、系数或单位转换逻辑。
单位不一致直接报错，px 和 rem 混用是常见翻车点
SCSS 对单位极其较真：14px + 0.2rem 会报错，1rem * 1.2 合法但结果仍是 1.2rem，不会自动转成 px。单位不会隐式转换，也不会静默丢弃。
- 统一单位再运算：定义
$base-font-size: 16px;，然后写font-size: (18px / $base-font-size) * 1rem; - 封装转换函数更安全：
@function px2rem($px) { @return $px / 16rem; }，调用font-size: px2rem(18); - 避免在媒体查询里写
calc(1rem + 4px)并指望 SCSS 处理——calc()是浏览器运行时行为，SCSS 编译器根本不解析它内部
响应式间距该用 calc() 而不是 Sass 运算
想让 margin 或 padding 随视口连续变化？$gap * 0.8 不行，calc(var(--gap) * 0.8) 才行。SCSS 算不出“当前宽度下的最优值”，因为容器尺寸在编译时根本不可知。
-
padding简写里用calc()容易失效（如padding: calc(2vw + 8px) calc(4vw + 16px)），务必拆成padding-top、padding-right等单方向声明 - 优先用
vmin：比如padding-left: calc(3vmin + 8px);比vw更稳，避免窄屏过小、宽屏过大 - 需要上限控制？
max(3vmin + 8px, 24px)在新浏览器可用，老环境得配媒体查询兜底：@media (min-width: 768px) { padding: 24px; }
真正容易被忽略的点：SCSS 函数不是魔法，它不感知 DOM
一个 @function px-to-vw($px, $base: 375px) { @return ($px / $base) * 100vw; } 看似聪明，但它生成的 width: 100vw; 是死的——如果页面有滚动条，iOS Safari 下 100vw 会多出滚动条宽度；如果根元素被 transform 缩放，它也不会跟着变。所谓“动态”，永远依赖运行时上下文，而 SCSS 只提供确定性、可复用的编译期表达式。别用它替代 calc()、clamp() 或 JS 监听逻辑。
立即学习“前端免费学习笔记（深入）”；
