应优先使用Number.isNaN()——它仅判断值是否为原生NaN而不转换类型，避免全局isNaN()隐式转换导致的误判，如isNaN(" 88 ")返回false而Number.isNaN(" 88 ")返回true。
关键在“是否转数字”——Number.isNaN()只认原装 NaN，不转换类型；全局 isNaN()先调用 Number() 转换再判断，容易把合法输入误判为 NaN。
明确使用场景：什么时候该用 Number.isNaN()
当你需要确认一个值本身就是计算失败产生的 NaN，而不是“看起来不像数字”的字符串或空值时，必须用 Number.isNaN()。
- 校验数学运算结果：比如
0 / 0、Math.sqrt(-1)、parseInt("abc")后的值是否真失效 - 配合显式类型转换后做精准判定：先写
const num = Number(input)，再用Number.isNaN(num)判断输入是否无效 - 避免把带空格的数字字符串（如
" 123 "）、布尔值（true）、null或空数组（[]）错当成 NaN
警惕全局 isNaN() 的隐式转换陷阱
它会默默执行 Number(value)，而这个转换规则常出人意料：
-
isNaN(" 88 ")→false（空格被忽略，转成 88） -
isNaN("88 元")→true（遇到“元”中断，整体转成 NaN） -
isNaN(null)→false（Number(null) === 0） -
isNaN({})→true（Number({})是 NaN） -
isNaN([1, 2])→true（数组转字符串再转数字，"1,2"无法解析）
替代方案与安全习惯
不用 === NaN（永远为 false），也不依赖全局 isNaN 做关键判定：
- 首选
Number.isNaN(value)—— 语义清晰、行为确定、现代环境全覆盖 - 需兼容 IE 等老环境时，可用
Object.is(value, NaN)，效果完全等价 - 对用户输入做数字校验，建议组合使用：
const n = Number(str.trim()); if (Number.isNaN(n)) { /* 拒绝 */ } - 若业务逻辑真需要“非数字即 NaN”的宽松语义（极少见），才考虑
isNaN，但务必加注释说明意图
本质上，Number.isNaN() 把判断逻辑收束到一个确定前提下：你已经拿到 number 类型，只关心它是不是 NaN；而全局 isNaN() 承担了“尝试解释一切”的职责，反而模糊了本意。守住这道边界，就能避开多数 NaN 相关的线上故障。
