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