为什么强类型在打字稿中丢失了‘Why’？

Question

有人能解释一下为什么下面的打字稿不能捕捉到打字问题吗？

function z(a: number) {
    console.log(a*a);
}

z(1); // works
z("xyz"); // fails type checking

function y(a: any){
    z(a); // I expect this statement to be erroneous
}

y(1); // works
y("xyz"); // does not fail type checking; feels like duck-typing?

在上面的例子中，编译器知道y被传递给一个string，因此z被传递一个字符串。这应该足以产生一个转换程序错误。有人能解释一下在预告片设计中做出的决定吗？

谢谢！:)

Answer 1

在y中，a有任何形式，因此它是一个有效的number，any是一个非常允许的对象，但是在您可能想说的情况下，我不知道a是什么，因此我可能想在调用z之前执行一些检查，然后应该使用unknown作为最小的允许类型。

function y(a: unknown){
  z(a); // Argument of type 'unknown' is not assignable to parameter of type 'number'.ts(2345)
  if (typeof a === 'number') {
    z(a) // all good
  }
}

any的存在是为了与现有的javascript代码兼容，或者为了安全转义，因为类型3.0分unknown是在不确定我们正在处理的类型时输入的类型，因此必须先缩小类型范围。https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type

Answer 2

有人能解释一下为什么下面的打字稿不能捕捉到打字问题吗？

y("xyz"); // does not fail type checking; feels like duck-typing?

那么方法y的签名是什么？

function y(a: any)

"xyz"是有效的any吗？是的。也就是说，a现在是any类型的，而不是string类型的。您已经显式地告诉编译器它是any，而不是string，所以由于any可以是number，所以调用是有效的。

在这方面，类型记录团队只是决定不对任何类型进行类型检查，因为Javascript允许这种类型的行为，并且类型记录组希望扩展/增强javascript，而不是阻止您做一些您想做的事情。any是一个可操作的特性，您可以使用类型记录编译器参数(或tsconfig.json)关闭implicitAny。