关于MDN中Array.prototype.includes()兼容代码的isNaN判断疑问

嘿，这个问题问得特别戳中JS的经典“反直觉”点！我刚学JS的时候也被NaN这个家伙坑过好多次😅，咱们一步步拆解清楚：

第一个关键：typeof NaN真的是'number' #

你没看错，这是JS语言设计的历史遗留特性——NaN（Not a Number）本身属于Number类型的特殊值，所以用typeof检测它的时候，返回的就是'number'。这听起来矛盾，但确实是ECMAScript规范里明确规定的。

第二个关键：isNaN(x)在这里的真实含义 #

你可能误以为isNaN()是判断“某个值是不是NaN”，但其实它的核心逻辑是：先尝试把参数转换成数字，如果转换失败（或者参数本身就是NaN），就返回true。不过在这个判断里，我们已经用typeof x === 'number'限定了x是Number类型，所以此时isNaN(x)返回true的唯一可能就是x本身就是NaN——因为其他Number类型的值（比如1、Infinity、-0）用isNaN()检测都会返回false。

这个判断存在的意义：处理NaN的“不相等”特性 #

JS里有个奇葩规则：NaN === NaN返回false（NaN是唯一不等于自身的值）。而Array.prototype.includes()的原生行为是：如果数组里有NaN，调用includes(NaN)应该返回true。但如果直接用===判断，就会识别不出两个NaN的匹配关系。

所以这个polyfill里的这段逻辑，就是专门用来补全这个场景：当要比较的两个值都是NaN时，手动判定它们是“匹配”的，这样就能让polyfill的行为和原生includes()保持一致。

举个实际例子验证：

const arr = [NaN];
// 原生includes会正确识别NaN，返回true
console.log(arr.includes(NaN)); // true

// 如果不用这段特殊判断，直接用===的话
console.log(arr.some(item => item === NaN)); // false

内容的提问来源于stack exchange，提问作者Vineesh