标签：组类型   为什么   上下文   也会   方式   信息   ural   style   情况   

　　类型推导就是在没有明确指出类型的地方，TypeScript编译器会自己去推测出当前变量的类型。

　　例如下面的例子：

let a = 1;

　　我们并没有明确指明a的类型，所以编译器通过结果反向推断变量a的类型为number，这种推断发生在初始化变量和成员，设置默认参数值和函数有返回值时。

　　大多数情况下，类型推导是直截了当的，但也有很复杂的情况，例如需要去匹配参数来推测类型。

　　最佳通用类型

　　当需要从几个表达式中推断类型时候，会使用这些表达式的类型来推断出一个最合适的通用类型。例如，

let x = [0, ‘fanqi‘, null];　　//(string | number)[]　

　　为了推断x的类型，我们必须考虑所有元素的类型。 这里有三种选择： number、string和null。 计算通用类型算法会考虑所有的候选类型，并给出一个兼容所有候选类型的类型。这个例子就是(string | number)[]。

　　由于最终的通用类型取自候选类型，有些时候候选类型共享相同的通用类型，但是却没有一个类型能做为所有候选类型的类型。例如：

let zoo = [new Rhino(), new Elephant(), new Snake()];

　　这里，我们想让zoo被推断为Animal[]类型，但是这个数组里没有对象是Animal类型的，因此不能推断出这个结果。 为了更正，当候选类型不能使用的时候我们需要明确的指出类型：

let zoo: Animal[] = [new Rhino(), new Elephant(), new Snake()];

　　如果没有找到最佳通用类型的话，类型推断的结果为联合数组类型，(Rhino | Elephant | Snake)[]。

　　上下文类型

　　TypeScript类型推论也可能按照相反的方向进行。 这被叫做“按上下文归类”。按上下文归类会发生在表达式的类型与所处的位置相关时。比如：

window.onmousedown = function(mouseEvent) {
    console.log(mouseEvent.button);  //<- Error
};

　　这个例子会得到一个类型错误，TypeScript类型检查器使用Window.onmousedown函数的类型来推断右边函数表达式的类型。 因此，就能推断出 mouseEvent参数的类型了。 如果函数表达式不是在上下文类型的位置， mouseEvent参数的类型需要指定为any，这样也不会报错了。

　　如果上下文类型表达式包含了明确的类型信息，上下文的类型被忽略。 重写上面的例子：

window.onmousedown = function(mouseEvent: any) {
    console.log(mouseEvent.button);  //<- Now, no error is given
};

　　这个函数表达式有明确的参数类型注解，上下文类型被忽略。 这样的话就不报错了，因为这里不会使用到上下文类型。

　　上下文归类会在很多情况下使用到。 通常包含函数的参数，赋值表达式的右边，类型断言，对象成员和数组字面量和返回值语句。 上下文类型也会做为最佳通用类型的候选类型。比如：

function createZoo(): Animal[] {
    return [new Rhino(), new Elephant(), new Snake()];
}

　　这个例子里，最佳通用类型有4个候选者：Animal，Rhino，Elephant和Snake。 当然， Animal会被做为最佳通用类型。

　　类型兼容性

　　TypeScript里的类型兼容性是基于结构子类型的。 结构类型是一种只使用其成员来描述类型的方式。 它正好与名义（nominal）类型形成对比。（译者注：在基于名义类型的类型系统中，数据类型的兼容性或等价性是通过明确的声明和/或类型的名称来决定的。这与结构性类型系统不同，它是基于类型的组成结构，且不要求明确地声明。） 看下面的例子：

interface Person {
    name: string;
}

class Father {
    name: string;
}

let person: Person;
// OK, because of structural typing
person = new Father();

　　在使用基于名义类型的语言，例如C#或Java中，这段代码会报错，因为Father类并没有明确说明其实现了Person接口。

　　TypeScript的结构性子类型是根据JavaScript代码的典型写法来设计的。 因为JavaScript里广泛地使用匿名对象，例如函数表达式和对象字面量，所以使用结构类型系统来描述这些类型比使用名义类型系统更好。

　　关于可靠性的注意事项

　　我们可以看到在以上的类型中，只要满足了子结构的描述，那么它就可以通过编译时检查，所以TypeScript的设计思想并不是满足正确的类型，而是满足能正确通过编译的类型，这就造成了运行时和编译时可能存在类型偏差。

　　所以TypeScript的类型系统允许某些在编译时无法确认其安全性的操作。当一个类型系统具有此属性时，被认为是“不可靠”的。而TypeScript允许这种不可靠行为的发生是经过仔细考虑的。下面我们会解释为什么需要这种特性。

　　开始

　　TypeScript结构化类型系统的基本规则是，如果x要兼容y，那么y至少具有与x相同的属性。例如：

interface Person {
    name: string;
}

let person: Person;
let y = { name: ‘fanqi‘, age: 25};
person = y;　

　　当将y赋值给person时，编译器会检查person中的每个属性，看是否能在y中也找到对应的属性。 在这个例子中，编译器发现y中也含有name属性，那赋值就是正确的，即使事实上并不准确。


检查函数参数时使用相同的规则：

TypeScript 类型推导及类型兼容性

标签：组类型   为什么   上下文   也会   方式   信息   ural   style   情况   

原文地址：https://www.cnblogs.com/fanqisoft/p/11988243.html