Number.isNaN 更可靠，因它只对数字类型且值为 NaN 返回 true，而全局 isNaN 会先强制转换类型再判断。替换时需确认参数已是数字类型、仅需排除 NaN、不依赖类型宽容；否则行为突变。
Number.isNaN 为什么比全局 isNaN 更可靠
全局 isNaN 会先尝试把参数转成数字再判断，导致 isNaN("abc")、isNaN(undefined)、isNaN({}) 全返回 true——它根本不是在问“是不是 NaN”，而是在问“转成数字后是不是 NaN”。Number.isNaN 则严格要求参数**必须是数字类型且值为 NaN**，其他任何类型（包括 undefined、null、字符串、对象）都直接返回 false。
哪些场景下替换后行为会突变
如果你原来用 isNaN 来做“宽松的非数字检测”，比如校验用户输入是否可解析为有效数字，直接替换成 Number.isNaN 很可能让逻辑失效。例如：
isNaN("123") // false（"123" → 123 → 不是 NaN）
Number.isNaN("123") // false（类型不是 number，直接 false）
isNaN("abc") // true（"abc" → NaN）
Number.isNaN("abc") // false（类型不是 number）
isNaN(undefined) // true（undefined → NaN）
Number.isNaN(undefined) // false（类型不是 number）
所以替换前要确认：你真正想判断的是「值是否为 NaN」，还是「输入是否无效/无法转为数字」。
安全替换的三步检查清单
只在满足以下全部条件时，才无风险地将 isNaN(x) 替换为 Number.isNaN(x)：
-
x的类型已确定为number（比如来自parseFloat、Number()或数学运算结果） - 你明确需要排除
NaN值本身（例如过滤掉计算失败的结果） - 你不需要捕获类型错误（如传入字符串、对象等非数字值）
常见安全场景：const result = Math.sqrt(-1); if (Number.isNaN(result)) { ... }；不安全场景：if (Number.isNaN(input.value))（input.value 是字符串）。
替代方案：需要类型宽容时该用什么
如果仍需类似原 isNaN 的宽松语义（即“转成数字后是否为 NaN”），但又想避免隐式转换带来的歧义，推荐显式转换：
function isValidNumber(value) {
const num = Number(value);
return !Number.isNaN(num) && isFinite(num);
}
// 或更轻量的判断“是否能转为有效数字”：
function isCoercibleToNumber(value) {
return Number.isNaN(Number(value)) === false;
}
注意：Number(" ") 是 0，Number("") 也是 0，这些都会被判定为“可转为数字”。真正要区分空输入和零值，得单独检查 value === "" 或 value.trim() === ""。
最常被忽略的一点：Number.isNaN 不处理 Infinity 和 -Infinity——它们是合法数字，Number.isNaN(Infinity) 返回 false。如果你的业务逻辑里要把无穷大也当作“异常数值”，得额外用 !isFinite(x) 配合判断。
