double.isnan() 是拦截 0.0/0.0 产生 nan 的最有效方式，因 java 遵循 ieee 754 标准，该操作不抛异常而返回非自等的 nan，需用标准方法识别，不可用 == 判断。
直接用 Double.isNaN() 检查除法结果，是最有效、最可靠的拦截方式。0.0 / 0.0 不抛异常，而是生成 Double.NaN，它不会自我相等，也不能用 == 判断，必须靠标准方法识别。
为什么 NaN 是除零拦截的关键信号
Java 遵循 IEEE 754 标准：浮点除零不报错，1.0 / 0.0 得 POSITIVE_INFINITY，0.0 / 0.0 数学上无定义，因此返回 NaN。这个值具有“传染性”——一旦出现，后续参与的加减乘除、函数调用（如 Math.sin、Math.log）结果仍为 NaN。所以，只要在关键除法后立刻检测，就能把问题卡在源头。
在量化计算中嵌入即时检测
量化常涉及归一化、缩放因子计算、信噪比推导等易触发 0.0 / 0.0 的环节（例如分母为零的动态范围、空数据块的标准差）。推荐在每次除法赋值后立即校验：
- 不做“先除后猜”，而是 除完就判：
double q = numerator / denominator; if (Double.isNaN(q)) { /* 中断或标记 */ } - 对批量处理循环，在每次迭代末尾加
if (!Double.isFinite(value))，一次性排除NaN和Infinity - 若使用
Math.sqrt或Math.log等函数，也需在其返回后检查——负数开方、零或负数取对数同样产出NaN
避免常见误判和陷阱
NaN 的判定极易出错，尤其在工程实践中：
-
绝不能写
result == Double.NaN—— 这永远是false；result != result虽数学成立，但受编译器优化（如-ffast-math）干扰，不可靠 - 不要用
!Double.isFinite(x)代替Double.isNaN(x)，因为isFinite对无穷大也返回false，会把Infinity误当NaN处理 - 若分母来自外部输入（如配置文件、传感器读数），建议前置守卫：
if (denominator == 0.0) throw new IllegalArgumentException("quantization denominator is zero")，比事后补救更清晰
封装成可复用的安全操作
在量化工具类中，可将高危运算封装为带语义的方法：
- 定义
safeDivide(double a, double b)，内部执行除法并用Double.isNaN()判定，返回Optional<double></double>或抛出自定义异常 - 对整批量化参数（如 scale、zeroPoint），提供批量校验入口，集中输出哪些索引位置产生了
NaN，便于定位数据源问题 - 生产环境开启日志埋点：记录触发
NaN的原始表达式（如"0.0 / stats.minVal"）、上下文参数、时间戳，辅助回溯
