是。Sass算术运算要求单位一致，否则报错；rem与px混合运算非法，需统一转换单位；vw等视口单位不可参与编译期运算，须用calc()交由浏览器运行时处理。
用 rem + px 混合运算时，Sass 会静默丢掉单位？
会。Sass 的算术运算要求参与运算的值单位一致，否则直接报错或返回无效值。比如 16px + 1rem 不合法，1rem * 1.2 合法但结果仍是 1.2rem —— 单位不会自动转换。
常见错误现象：font-size: 14px + 0.2rem 编译失败，控制台提示 “Incompatible units: ‘px’ and ‘rem’”。
- 统一转成
rem：先定义根字体基准（如$base-font-size: 16px），再用14px / $base-font-size得到0.875rem - 封装一个转换函数：
@function px2rem($px) { @return $px / 16rem; }，后续写font-size: px2rem(18); - 别在媒体查询里硬写
calc(1rem + 4px)交由 Sass 算——那是运行时行为，Sass 编译期不处理calc()内部
@media 中用 em 做断点，Sass 怎么安全缩放间距？
用 em 断点本质是依赖用户设置的浏览器默认字号（通常 16px），所以所有响应式尺寸最好都基于同一基准推导，避免嵌套换算失真。
使用场景：组件需要随根字号缩放，同时断点也随用户偏好变化（比如系统设为 20px，默认 1em = 20px）。
立即学习“前端免费学习笔记（深入）”；
- 定义统一基准变量：
$root-base: 16px，所有尺寸按比例写，如$space-sm: 0.5rem（即 8px） - 断点用
em值：@media (min-width: 48em) { ... } → 这里48em = 48 × $root-base，和$space-sm同源 - 切忌混用：
margin: 0.5rem 12px看似省事，但12px在 20px 根字号下不会放大，破坏一致性
动态计算边距时，map-get + scale 函数怎么防溢出？
用 map 存不同屏幕尺寸下的缩放系数（如 (sm: 0.8, md: 1, lg: 1.2)），再配合 scale 函数生成间距，容易因系数过大导致负边距、文字重叠等视觉溢出。
性能影响：每次调用 scale 都是编译期计算，无运行时开销，但系数设计不合理会让生成的 CSS 值失去语义（比如 margin-top: -2.4rem）。
- 加边界检查：
@function scale-space($key, $base: 1rem) { $ratio: map-get($space-ratios, $key); @return if($ratio > 0, $base * $ratio, 0); } - 预留 fallback：对超大系数（如 > 2）强制截断，
min($ratio, 1.5) - 别把缩放逻辑塞进 class 名：避免生成
.m-t-1-75x这类不可维护的类名，优先用语义化命名 + 局部覆盖
Sass 编译后单位固化，vw/vmax 还能动态响应吗？
不能。Sass 是预处理器，所有运算都在构建时完成，100vw / 3.75 会被算成固定像素值（如 42.66667vw？错——它根本不会算，因为 vw 是运行时单位，Sass 不支持含视口单位的运算）。
错误现象：width: 100vw / 3.75 编译直接报 “Invalid CSS after ‘100vw’: expected expression”。
-
vw、vmax、ch等必须原样输出，不能参与 Sass 数学运算 - 需要动态响应的场景（如满屏三栏），改用
calc()：width: calc(100vw / 3.75)—— 注意这是浏览器运行时计算，Sass 只负责原样透传 - 如果非要 Sass 辅助，只能做字符串拼接：
@function vw($value) { @return #{$value}vw; }，但毫无运算能力
最易被忽略的一点：很多人以为 @media (width >= 768px) 能替代 em 断点，其实它和视口宽度强绑定，而用户缩放、系统字号调整时，em 断点才真正“响应”人，不是只响应屏幕。
