Number.isNaN 更适合业务校验，因其不进行类型转换，仅识别真正的 NaN 值；而全局 isNaN 会先调用 Number() 转型，导致非数字输入（如 "abc"）误判为 NaN，掩盖真实问题。
Number.isNaN 为什么比 isNaN 更适合业务校验
因为 Number.isNaN 不做任何类型转换，只认“原装 NaN”——即 JavaScript 内部那个真正由非法数学运算（如 0 / 0、Math.sqrt(-1)、5 + "a"）产生的、类型为 "number" 且值为 NaN 的值。而全局 isNaN 会先调用 Number() 转型，导致 isNaN("abc")、isNaN(undefined) 都返回 true，把类型错误伪装成数值错误，掩盖真实问题。
什么时候必须用 Number.isNaN 而不是直接比较 === NaN
因为 NaN !== NaN 是 JavaScript 的硬性规定，任何直接用 === 或 == 判断 NaN 的写法都必然失败。你无法靠相等性检测识别它。
-
result === NaN→ 永远是false -
result == NaN→ 永远是false -
Number.isNaN(result)→ 唯一可靠方式，只在result确实是NaN字面量时返回true
典型业务场景中如何嵌入 Number.isNaN 校验
常见于计算器、表单数值解析、API 返回值预处理等需要区分“真 NaN”和“非数字输入”的环节。关键点：先转数字，再判 NaN，不跳步。
- 对用户输入做
Number(input)转换，得到num - 立刻用
Number.isNaN(num)判断是否转换失败（注意：空字符串""转为0，不是NaN；" 123 "也会成功转为123） - 若为
true，说明原始输入根本无法解释为有效数字（如"abc"、"12px"、null），应提示格式错误 - 若为
false，再检查isFinite(num)排除Infinity和-Infinity
示例：
function parseNumberInput(input) {
const num = Number(input);
if (Number.isNaN(num)) {
throw new Error(`无效数字输入: "${input}"`);
}
if (!isFinite(num)) {
throw new Error(`超出数值范围: "${input}"`);
}
return num;
}
容易忽略的兼容性与边界坑
Number.isNaN 是 ES6+ 特性，在 IE 全系及部分旧版安卓 WebView 中不可用。若需兼容，不能简单 polyfill Number.isNaN = Number.isNaN || function(v) { return v !== v; } —— 因为该逻辑在 v 为 undefined 或 null 时也成立（undefined !== undefined 是 true？错，undefined === undefined 是 true，但 undefined !== undefined 是 false；真正风险在于 Symbol()、{} 等非数字类型传入后行为未定义）。稳妥做法是只在明确已调用 Number() 得到数字类型的前提下才用自检逻辑。
更实际的建议：业务代码中统一走 Number() + Number.isNaN() 组合，构建层用 Babel 或现代打包工具处理兼容性，不手写降级逻辑。
