在这种情况下，TypeScript 类型系统是否过于宽松？

Question

我想我遇到了一种情况，它似乎应该导致 TS 编译器出错（但事实并非如此），我希望有人能解释原因。

在下面的代码中，我将接口Foo 传递给它接受的函数frobnicator。然后，在frobnicator 的正文中，我“删除”了bar.y 字段。在frobnicator 终止后，类型系统允许我打印bar.y（没有错误），尽管y 不再存在。

类型系统不应该禁止我将foo 传递给frobnicator，因为现在foo 不再实现Foo 接口并且TS 认为它实现了吗？

interface Foo {
    bar: { x: number, y: number };
}

function frobnicator(thing: { bar: { x: number } }) {
    thing.bar = { x: 1 }; // "remove" bar.y
}

const foo: Foo = { bar: { x: 1, y: 2 } };
frobnicator(foo); // The implementation "removes" bar.y
console.log(foo.bar.y); // TypeScript does not error despite bar.y missing

Answer 1

答案是肯定的，您的代码演示了 Typescript 类型系统的不健全行为，这正是您在问题中描述的原因。

答案也是否定的，你没有“破坏” Typescript 的类型系统，因为这种不健全的行为是预期的行为。打字稿并不完全正确，也不意味着完全正确；引用the docs:

TypeScript 的类型系统允许某些在编译时不知道的操作是安全的。当一个类型系统具有这个属性时，就说它不是“健全的”。仔细考虑了 TypeScript 允许不良行为的地方，在本文档中，我们将解释这些情况发生的位置以及它们背后的动机。

Typescript 的设计者明确选择了稳健性和实用性之间的平衡；完全健全的类型系统不会将 {bar: {x: number, y: number}} 视为 {bar: {x: number}} 的子类型，但真正的 Javascript 代码通常会传递具有比函数实际访问的属性更多的对象，因此严格健全的行为对开发人员来说不是很有用编写逼真的 Javascript 代码的人。

Answer 2

您的接口与函数内的代码无关，因为即使您的 const 的类型是 Foo，该函数接受的不是 foo，而是未命名的类型 { bar: { x: number } }。由于 Typescript 在 compile time 而不是在 runtime 中工作，因此它不可能知道您的函数已删除 y，因为函数内部的类型没有 y 和它外面的类型是Foo，它是函数参数类型的超类型，因此它的实例适合参数的类型。所以，一方面你的函数从对象中删除了一个字段，但是你没有告诉编译器它是被禁止的，因为函数内部的类型与你传入的类型不同，所以外部它仍然认为你有 @ 987654325@。在像 Java 这样的语言之后，这似乎违反直觉，但事实就是如此。为避免此类问题，您应该使用正确的类型，例如，在函数中使用您的接口类型。

Answer 3

该函数只需要一个嵌套字典。 不是确切的密钥数量。