math.div()本身不导致错乱，而是暴露隐性错误：单位不匹配（如math.div(1.5rem, 16)得0.09375rem而非无单位比值）、漏@use导致函数未定义、参数为null/map、混用单位（px/rem）、循环中滥用致编译膨胀。
直接原因几乎总是单位处理错误或函数调用时机不对——math.div() 本身不会导致错乱，但它把隐性错误提前暴露了。
为什么 math.div() 一加进去页面就崩了
不是函数有问题，是它戳破了旧写法的“侥幸”。比如原来写 width: 100% / 3，Sass 旧版本可能静默跳过、留着原样输出（浏览器还能解析），但换成 math.div(100%, 3) 后，编译器必须算出一个确定值；一旦参数类型不对、单位不匹配、或除零，立刻报错或返回 Infinity，样式直接失效。
- 常见触发点：
math.div($value, $base)中$value是null或 map，而错误直到实际渲染时才在某个 class 里爆发，堆栈指向很远 -
math.div(1.5rem, 16)返回0.09375rem，但你真正想要的是无单位比值0.09375，结果被当成了长度参与后续计算，尺寸全乱 - 漏掉
@use "sass:math"，函数未定义，整个变量链坍塌，依赖它的$spacing-sm、$font-size-lg全变成undefined
单位不一致导致 math.div() 返回意外值
math.div() 要求两个参数单位兼容，否则要么报错，要么结果带反直觉单位（比如 px⁻¹）。最典型的是混用 rem 和纯数字做比例换算。
- 错：
math.div(1.5rem, 16)→ 得到0.09375rem（单位还在） - 对：
math.div(1.5rem, 1rem)得1.5（无单位），再除以16得0.09375 - 更安全：用
unitless($val)判断，分支处理：@if unitless($val) { @return math.div($val, 16); } @else { @return math.div(math.div($val, 1rem), 16); } - 别信“自动转换”——
math.div(100px, 1em)在根字号非 16px 时结果不可控，应统一转成rem或px再算
在 mixin 或循环里滥用 math.div() 加剧编译膨胀
每次调用 math.div() 都是一次编译期计算。如果在 @for 循环里反复算同一组值，或在嵌套很深的 mixin 中层层传参再除，不仅拖慢构建，还容易因中间变量单位丢失引发连锁错乱。
- 提取公共计算：把
$gap-unit: math.div(16px, 2)提前定义，循环里直接用$gap-unit - 避免深层传递：不要写
@mixin pad($size) { padding: math.div($size, 2); }然后传入1.5rem—— 改为@mixin pad($size) { padding: math.div($size, 2); }并确保调用方已做好单位归一 - 检查是否真需要编译时计算：如果值依赖
--col-count这类 CSS 变量，math.div()根本无效，必须切回calc()
最容易被忽略的其实是上下文污染：一个文件里 @use "sass:math" as math，另一个文件没写这句却直接用 math.div()，Dart Sass 不报错但函数不可用，变量无声退化为空值——错乱往往从这种“半启用”状态开始蔓延。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
