SCSS中$a / 0不报错是因为它是编译时预处理器，静默返回NaN导致CSS声明失效；需用@function封装+@if检查分母并@warn提示，否则浏览器丢弃margin: NaN等无效值。
SCSS 编译器不会抛出“除以零异常”，也不会中断编译 —— 它只是静默返回 NaN 或无效值，后续样式可能失效或被浏览器忽略。
为什么 SCSS 里写 $a / 0 不报错但结果不可用
SCSS 是编译时预处理器，不是运行时语言。它的数学运算发生在 CSS 生成前，@debug 或 @warn 可以暴露问题，但编译器默认不中止流程。比如：
$gap: 16px;
$scale: $gap / 0; // 不报错，$scale 值为 NaN
.test { margin: $scale; } // 编译后变成 .test { margin: NaN; } → 浏览器直接丢弃该声明这种错误不会出现在终端报错里，只会导致样式“消失”，调试成本高。
-
NaN值无法参与后续计算（如$scale * 2仍是NaN） - 浏览器解析 CSS 时遇到无效值（如
margin: NaN）会跳过整条声明，不报控制台错误 - 没有类似 JavaScript 的
try/catch机制，无法在 SCSS 中主动捕获
用 @if + @warn 主动拦截除零风险
唯一可行的防御方式是：在执行除法前，显式检查分母是否为 0、null 或 NaN，并用 @warn 提示开发者。
立即学习“前端免费学习笔记（深入）”；
@function safe-div($a, $b) {
@if $b == 0 or $b == null or $b != $b { // $b != $b 判断 NaN
@warn "Division by zero or invalid value in safe-div(#{$a}, #{$b})";
@return 0; // 或其他 fallback 值，如 auto、1rem 等
}
@return $a / $b;
}
<p>.foo { width: safe-div(100%, 0); } // 终端输出 warning，编译继续- 必须用函数封装，不能对裸表达式做检查
-
@warn仅在终端打印提示，不影响编译，但能暴露问题位置 - 返回值需与上下文类型兼容（如单位不匹配会导致新错误）
哪些场景最容易踩坑：变量来源不可控时
当你从设计系统变量、配置文件或第三方 mixin 接收数值时，分母可能来自 @import 的 partial 或 @use 模块，此时静态检查更难覆盖。
- 使用
@use "vars" as v引入的v.$spacing-unit为0，而你在@include make-grid($cols / v.$spacing-unit)里直接除 - 通过
map-get($config, "ratio")获取的值未校验就用于计算 - Sass 的
unitless()函数误判带单位数值（如unitless(0px)返回true），导致逻辑分支走错
这类问题不会触发编译失败，但生成的 CSS 里会出现大量 NaN 或 auto，最终表现为布局塌陷或间距归零 —— 而你可能花半小时才意识到是某个基础变量被设成了 0。
真正要盯住的不是“如何捕获”，而是“谁提供了分母”
SCSS 没有运行时异常机制，所谓“处理错误”本质是工程约束：把除法操作收口到少数可审计的函数里，并强制所有调用方经过该函数。
- 禁用裸除法：在团队 ESLint 配置中启用
stylelint-scss的no-duplicate-dollar-variables和自定义规则拦截/\s*0\b模式 - 分母变量命名加标识：如统一用
$base-ratio而非$r，并在文档中标注“此值不得为零” - 构建阶段加验证脚本：用 Node.js 读取编译前的 SCSS 文件，正则扫描
/[\/]\s*(0|null|false)/i并提前退出 CI
最常被忽略的一点：Sass 的 0 和 0px 类型不同，0 == 0px 返回 false，所以检查时得分别应对 —— 这让防御逻辑比表面看起来更琐碎。
