为什么TypeScript中的isNaN强制要求传入数字类型参数？

我知道Stack Overflow上有不少关于isNaN不接受字符串、仅接受数字的问题，我的疑问在于该设计的动机，对此无法理解。我使用TypeScript是为了借助类型系统获得帮助并信任它。要使用isNaN，我必须按以下步骤操作：

• 获取字符串形式的数字
• 将其转换为数字：var num = Number(myStrNum);
• 调用isNaN(num);

我的观点是，步骤2之后，TypeScript类型系统会将其视为数字，即便它并非有效的数字，这意味着我无法信任数字类型一定不是NaN。确实存在其他类似情况，但此处是TypeScript的定义设计强制了该行为，而JavaScript本身允许传入字符串参数。为何会做出这样的设计决策？

TypeScript对isNaN的类型约束，核心是对齐语言语义一致性、强化类型系统严谨性，具体原因可以从这几点拆解：

1. 修正原生JS的设计缺陷
   原生JS的isNaN存在历史遗留问题：它会先对传入参数做隐式数字转换，比如isNaN("abc")会返回true，但"abc"本身并不是NaN——这种“转换+判断”绑定的逻辑极易造成语义误解，甚至引发隐蔽bug。TypeScript通过类型约束强制要求传入数字，本质是在类型层面就规避这种模糊用法，明确isNaN的定位：仅用于判断一个数字值是否为NaN，而非判断某个值能否转为有效数字。

2. 尊重JS原生类型语义
   你提到“数字类型可能包含NaN”是事实，但这不是TypeScript的漏洞，而是JS本身的语言特性——在JS里，NaN属于number类型的一员。TypeScript的类型系统是JS类型的超集，它不会篡改原生类型的本质，而是在这个基础上做约束强化。强制isNaN接收数字参数，是为了让开发者明确：字符串转数字后，结果可能是有效数字或NaN，此时调用isNaN是在做明确的数字有效性校验，而非依赖原生JS的隐式模糊判断。

3. 引导清晰的编码逻辑
   TypeScript的设计理念之一是让代码意图更明确。如果允许直接给isNaN传字符串，本质是把“类型转换”和“NaN判断”两个逻辑混在一起，代码可读性和可维护性会下降。强制先转数字再判断，是引导开发者拆分逻辑：先完成类型转换，再对转换结果做有效性校验，这符合清晰的编码习惯。

如果需要直接判断字符串是否能转为有效数字，你可以封装更明确的工具函数：

function isNumeric(str: string): boolean {
  const num = Number(str);
  return !isNaN(num) && isFinite(num);
}

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