最近在准备前端晋升答辩和面试题时不少人都盯着 TypeScript 的类型系统发愁明明已经开了 strict 模式为什么有些函数类型赋值还是会报错协变和逆变到底怎么理解更让人困惑的是大家都在说函数参数是逆变的可直觉里总感觉参数应该越具体越好。第一次听到这个结论时我也很懵——后来在一个回调类型的 bug 上折腾了大半天才真正明白这不是冷门概念而是类型系统安全性的核心。这篇文章就从我自己的踩坑经验出发把协变、逆变和函数参数的逆变原理讲透配合代码示例和常见问题排查给出在实际代码里可落地的检查与修正方案。无论你是刚开始学 TypeScript 的初学者还是维护过大型类型系统的开发者都能从中找到熟悉的问题或更稳妥的写法。1. 变型是什么从“谁能替换谁”说起1.1 子类型与可赋值性的底层直觉理解协变和逆变之前必须先建立两个基础概念子类型和可赋值性。在 TypeScript 里如果一个类型 A 的实例可以安全地赋值给类型 B 的变量我们就说 A 是 B 的子类型。比如interface Dog { name: string; breed: string }interface Animal { name: string }那么 Dog 就是 Animal 的子类型因为 Dog 不仅拥有 Animal 的全部属性还额外有 breed。这种结构性比较跟 Java 那种名义类型系统有本质区别它只看形状不看名字这也是 TS 能这么好用的原因之一。可赋值性是子类型关系的运行时反映。当你写const pet: Animal new Dog()时编译器只需要确认 Dog 的结构覆盖 Animal 所需的所有属性就能放行。这里的核心是替换安全性一个变量声明成 Animal代码就只会按 Animal 的接口去访问它给它一个 Dog 不会有任何副作用。这个替换安全性是后续讨论变型的基石。一旦我们把这种二元关系投射到泛型、数组、函数等复合类型上就会发现方向成了一个真正的问题。什么叫方向性问题假设我有BoxDog和BoxAnimal。如果BoxDog能赋值给BoxAnimal说明这个盒子对泛型参数 T 是协变的如果反过来BoxAnimal能赋值给BoxDog就是逆变如果两个方向都无法保证则是不变。变型描述的就是一个复合类型在泛型参数变化时可赋值性方向是保持还是反转。具体到 TypeScript数组、Promise 是典型的协变容器函数参数又是一个需要特别关注的逆变位置。1.2 用“生产者和消费者”理解协变与逆变生产者和消费者是两个很形象的标签。一个只负责产出 T 的容器对 T 是协变一个只负责接收 T 的容器对 T 是逆变如果既要输入又要输出 T那这个容器对 T 往往是不变。原因很简单产出侧你可以给一个更具体的结果使用方按宽类型接收永远是安全的输入侧正好相反使用方可能送进来一个宽类型的值接收方如果只认窄类型就装不下。生活化例子更好懂。一家宠物食品工厂可以生产狗粮和猫粮但它给客户清单上写“宠物食品”是没问题的客户要什么自己在清单里挑。反过来一个只有“狗粮”的自动喂食器你把溢出的“宠物食品”倒进去狗还能吃但如果这个喂食器只接受“宠物食品”你非要塞一把“狗粮”理论上也可以——方向已经反了。函数也是一样函数消费参数、生产返回值。消费端需要能接纳外部可能传入的所有值所以它应该更宽生产端对外承诺一个足够具体的类型所以它应该更窄。这个原则放到 TypeScript 里并不是空洞的比喻而是类型检查器防止两类运行时事故的方向依据一类是拿 Cat 传给只处理 Dog 的函数另一类是拿到PromiseCat却当成PromiseDog来用。后面你会看到strictFunctionTypes 开的实际上就是一套沿着这种方向规则做结构比较的算法。2. 为什么函数参数必须是逆变的2.1 从函数调用契约推导参数方向我们先拿出两个函数类型来推演type F (arg: Animal) string;和type G (arg: Dog) string;。从直觉上看Dog 是 Animal 的子类型似乎 F 比 G 更“能用”我们需要用调用契约来检验。假如我把一个类型为 F 的变量赋值给一个类型为 G 的变量那么当其他代码通过 G 来调用这个变量时它按照 G 的契约只会传入 Dog因为 G 的参数类型就是 Dog。F 能处理所有 Animal自然也能处理 Dog因此这个赋值是安全的。这就是参数逆变拥有更宽参数类型的函数可以赋值给需要更窄参数类型的函数。反过来如果把一个 G 赋值给一个 F会怎样F 的调用方认为参数类型是 Animal可能传入 Cat 或者其他更宽泛的动物但 G 内部的实现只认 Dog它会在运行期尝试调用breed或bark()一遇到 Cat 就崩。所以这个赋值必须被禁止。用一句口诀总结参数位置是输入输入要求宽容不能比目标更窄返回值位置是输出输出要求具体不能比目标更宽。把方向反过来的赋值就是变型系统要拦住的错误。2.2 具体例子两个函数类型谁能赋给谁我写一个可以直接粘贴运行的例子。定义 Animal 和 Dog 两个接口之后再定义两个函数类型别名AnimalHandler接收 AnimalDogHandler接收 Dog。然后声明一个handleAnimal函数它接收 Animal 并返回字符串。把它赋给DogHandler时TS 会放行因为你已经把“什么动物都能处理”的处理器升级成了“至少能处理 Dog”的处理器。interface Animal { name: string; } interface Dog extends Animal { breed: string; bark(): void; } type AnimalHandler (animal: Animal) string; type DogHandler (dog: Dog) string; const handleAnimal: AnimalHandler (animal: Animal) my ${animal.name}; const handleDog: DogHandler handleAnimal; // OK参数逆变但如果你反过来写TS 会报Type DogHandler is not assignable to type AnimalHandler错误信息里会把两个参数Dog和Animal的不兼容方向标出来。很多人第一眼看到这个错误会觉得很反直觉Dog 不是 Animal 的子类型吗怎么就不能用了注意这里比较的是函数本身不是参数对象。函数在参数位置的要求是“你的参数必须比我契约里的参数更宽”不是“更窄”。日常开发中这个安全通道非常实用。比如事件总线里监听 Dog 事件你只需要提供一个能处理更宽泛的 Animal 回调就可以把同一个函数复用到 Dog、Cat 多个事件上。反过来你却做不到一旦你把只处理 Dog 的回调接到一个可能触发 Animal 事件的通道上线上就会莫名其妙报错。逆变规则就是帮你在编译期拦下这最后一根雷。2.3 返回值协变两者为什么相反再看返回值的协变它和参数方向正好相反。type GetAnimal () Animal; type GetDog () Dog;。现在GetDog可以赋值给GetAnimal因为调用方只期望从返回值里拿到一个 Animal 的能力实际收到一个更具体的 Dog完全没问题。反过来GetAnimal不能赋值给GetDog因为调用方可能需要bark()或breed你却只返回了一个没有这些能力的 Animal。type GetAnimal () Animal; type GetDog () Dog; const getDog: GetDog () new Dog(); const getAnimal: GetAnimal getDog; // OK返回协变所以说函数类型不是整体上“协变”或“逆变”而是参数位置遵循逆变、返回位置遵循协变。这样设计才能同时满足“我能安全调用你”和“你能安全给我想要的东西”两个条件。理解了这一点再去看strictFunctionTypes那类错误提示就会觉得非常合理。3. TypeScript 检查规则与严格模式3.1 strictFunctionTypes 开启下的参数检查TypeScript 真正把逆变纳入编译期检查是从 2.6 版本的strictFunctionTypes开关开始的。如果你在 tsconfig.json 里开了strict: true它会默认开启。它只对函数类型字面量、函数类型声明这些独立函数形态生效不会管接口或类里的方法声明。这也解释了为什么很多人明明开了 strict遇到某些回调还是能绕过检查——问题很可能出在声明写法。type AnimalHandler (animal: Animal) void; type DogHandler (dog: Dog) void; const hAnimal: AnimalHandler (animal: Animal) {}; const hDog: DogHandler hAnimal; // OK // 下面这行在 strictFunctionTypestrue 时会被拦下 const hAnimal2: AnimalHandler hDog; // 参数类型不兼容实际项目中如果把strict: false这种错误会被忽略进而埋下运行时炸弹。我建议所有新工程都用strict: true老项目至少单独打开strictFunctionTypes同时把noImplicitAny打开。真正落地时一旦某个回调参数隐式 any逆变检查也会跟着失效。如果一个类型因历史原因必须保留可以使用类型断言并写清楚守卫条件而不是直接关检查。3.2 方法参数的双变一个历史包袱最让人困惑的是方法method参数的双变。同样是接收 Animal 的函数如果你在接口里这样声明interface Cage { add(animal: Animal): void }那么实现时写add(dog: Dog) { dog.bark() }TS 不会报错。这里参数方向既可以逆变也可以协变所以这种不安全的协变实现也被放行了。你可能会问TS 为什么明知不安全还要容忍答案是历史兼容压力。在引入 strictFunctionTypes 之前所有函数参数本身就是双变检查大量库和业务代码已经依赖这种宽松行为。如果直接把方法参数改成严格逆变Array、Map 以及各种事件监听的类型定义会瞬间破功几乎是一场地震。TS 的取舍是把严格的逆变检查放在了函数类型function type而方法声明继续保留双变这样既能让新写的函数类型获得安全收益又不必重构整个生态。现在社区普遍推荐的写法是定义函数形状的结构时尽量别用接口方法改用函数属性。比如interface Cage { add: (animal: Animal) void }这样参数位置会接受严格逆变检查。ESLint 里有一个method-signature-style规则可以强制团队代码采用这种属性签名从根源上减少双变导致的类型漏洞。如果你在维护自己的类型定义可以做一个简单自查凡是接口或 class 里以foo(x: X): Y形式声明的成员都看看是否有必要改成foo: (x: X) Y。前者更符合面向对象风格后者更接近安全意识强的函数式风格。从运行效率看两者没差别但从类型安全看差别经常直接体现在是否能拦截一个运行时 bug。3.3 泛型与常见高阶函数的变型表现泛型类的变型不是靠关键字指定的而是由它的成员位置自动决定。PromiseT里 T 出现在 then 回调的返回值中所以是协变ReadonlyArrayT里 T 只出现在读取位置也倾向协变但Animal[]这种可写数组同时有读取和写入方法正常情况下应该是不变的TS 为了实用主义仍然把它当作协变处理代价是留下了一个“push 一个 Animal 到 Dog[]”的风险点这个问题我放在后面常见问题里展开。至于高阶函数和回调Array.prototype.forEach、map、filter的回调类型定义都使用了泛型约束它们在参数位置上通常走的是参数逆变但因为有方法签名的双变兜底很多严格模式下不该放行的写法也可能被放行。比如[].map((value: Dog) value.name)作为Animal[]的 map 回调TS 会报错吗这取决于你赋值的上下文。如果你把它显式赋给(value: Animal) string在 strictFunctionTypes 下会报错如果直接写在数组方法的参数里T 已经被推断为 Animal你的回调声明 Dog自然不满足逆变。这里的问题和“函数参数逆变”是同一个原理只是包装在泛型调用里错误信息更绕。所以在看这类错误时我的习惯是先把泛型方法展开成函数类型看看这个函数类型当前接受的参数是宽还是窄再判断是不是逆变问题。不要被泛型推导干扰了判断。4. 实操技巧与问题排查4.1 五个会踩坑的典型场景下面五个场景是我在 Code Review 和排查线上问题时反复遇到的。先看一个总览表再逐个拆开讲。典型场景报错表现核心原因回调参数收窄目标参数是Animal你传(dog: Dog)void报类型不兼容参数逆变窄参数不能赋给宽参数位置事件监听器自己封装的事件回调参数是宽Event传入(e: KeyboardEvent)void报错事件 API 没有泛型化参数逆变被激活接口方法签名方法参数用子类型实现但没有报错方法参数是双变TS 默认放行泛型函数泛型 T 推断成 unknown导致(dog: Dog)void无法匹配泛型缺失推断来源逆变方向不满足第三方类型声明第三方库回调参数定义成any或方法声明问题被隐藏类型定义规避了严格检查第一类回调参数收窄。一个组件或工具库声明了(value: Animal)void你传给它的内部函数却把参数写成(dog: Dog)void并且这个函数内部调用了 Dog 专属方法。strictFunctionTypes 直接报错但很多人直接加as绕过反而把运行风险引入线上。正确做法应该是调整回调参数或者内部做类型守卫。第二类事件监听器。DOM 的addEventListener因为使用泛型keydown会自动把回调参数收窄成 KeyboardEvent所以你很少遇到逆变报错。但你自己封装事件总线时如果没有泛型化处理回调参数往往会是宽 Event此时传入窄事件处理函数就会报错。正确做法是给事件总线加泛型映射而不是强行断言。第三类接口方法签名导致的静默放宽。这种最危险因为不报错。比如interface Service { save(state: AppState): void }实现里写save(localState: LocalState): voidTS 因为方法是双变的直接放行。等线上真的传入了其他状态时局部状态里的字段可能为空逻辑直接崩。如果你在维护这个接口把方法签名改成函数属性错误马上会暴露。第四类泛型函数推断方向不明确。function withCallbackT(cb: (t: T) void): void里如果没有给 T 提供来源TS 会把 T 推断为 unknown此时你传入(dog: Dog)void反而会报参数不兼容因为 unknown 不是 Dog 的父类型不能满足逆变。解决方式是给 T 一个合理的约束或来源比如T extends Animal并让泛型从调用参数或返回值推断。第五类第三方库的类型声明。很多库为了兼容 TS 老版本方法参数广泛使用双变或 any。如果你在这些类型之上做二次封装别照着第三方类型直接断言先看官方类型是方法声明还是函数属性。是方法声明可以考虑自己包一层更严格的行为函数把类型安全留给团队。4.2 解决函数参数逆变问题的三种改法面对逆变导致的报错我不建议用类型断言强行压下去。更稳的方案有三个宽参数 内部守卫、泛型约束、显式标注函数类型。第一种最简单把函数参数改成目标类型要求的宽类型在函数体里用instanceof或自定义类型守卫手动缩小。比如目标要求(animal: Animal)string你内部想处理 Dog 的 breed就用if (breed in animal)判断分支而不是让参数直接写成 Dog。const withGuard: (animal: Animal) string (animal) { if (breed in animal) { return dog: ${animal.breed}; } return animal: ${animal.name}; };第二种是用泛型约束把具体类型交给调用的上下文决定。比如定义一个createObserverT extends Animal(handler: (value: T) void)使用方传 Dog 时回调参数就推断为 Dog传 Animal 时就是 Animal。这种方式最灵活但要小心参数 T 的推断来源。如果 T 没有真实的调用参数很容易被推断成 unknown反而带来新的错误。第三种是显式标注函数类型在赋值时就把目标类型标注出来。很多时候不是不兼容而是 TS 没有合适上下文去推断函数参数的起点。例如const handler: DogHandler (dog) { dog.bark(); };这时参数 dog 会被推断成 Dog但如果你写const handler (dog) { dog.bark(); };且 noImplicitAny 关闭dog 就是 anyTS 不会帮你检查。显式标注能让逆变规则真正生效。三种方案里我最推荐宽参数 类型守卫它不牺牲类型安全学习的成本最低也最能应对真实业务里“参数类型比你想象得宽”的情况。至于泛型适合设计通用工具时使用但在业务组件里滥用泛型会让 props 的类型组合爆炸反而更难维护。4.3 一次完整的排查实录讲一个我真实踩过的坑。当时我要封装一个跨组件的事件总线对外提供onDog(cb: (dog: Dog)void)和onAll(cb: (animal: Animal)void)。有个业务方觉得onDog和onAll的 handler 都差不多于是写了const handler (animal: Animal) handle(animal)然后onAll(handler)正常可当他把const handler2 (dog: Dog) handleDog(dog)传给onAll时tsc 立刻报错。报错信息大概是Type (dog: Dog) void is not assignable to type (animal: Animal) void。说实话当时的我第一反应是“狗不是动物吗怎么不能用了”。我花了一会儿才反应过来这是参数逆变问题。解决方式也不复杂我在 handler2 内部加了if (animal instanceof Dog) {...}这种守卫逻辑同时在onAll的类型定义里仍然保留宽参数。后来我又给事件总线加了一个泛型方法onEventT extends keyof Events(event: T, cb: (payload: Events[T]) void)让调用方自己决定 payload 类型整体上更安全也避免了业务方在不同事件上反复写宽参数。这次排查看似简单但它让我养成了一个习惯任何函数类型的赋值报错先到类型定义里确认目标参数的类型宽度再检查当前函数参数的类型宽度。如果当前参数比目标窄要么把当前参数调宽要么加守卫。不要用as绕过否则你只是把编译器端的错误推迟到了运行端。5. 常见问题速查面试与代码中的高频疑点5.1 面试怎么答“为什么函数参数是逆变的”如果面试官抛出这个问题不要只背一句话。把推导过程讲出来比结论重要。我的作答框架是先定义子类型和可赋值性然后从函数调用方的视角出发——目标函数类型决定了调用方会传什么参数、期望拿什么返回值。假设我要把(animal: Animal)void当成(dog: Dog)void用调用方只会传 Dog而它什么 Animal 都能处理安全反向则不行调用方可能传 Cat但它只认 Dog。所以参数方向必须是逆的返回值方向必须是顺的。最后补一句TS 通过 strictFunctionTypes 开启严格逆变但方法声明为了兼容历史参数还是双变。这套回答基本能把考点覆盖完整。5.2 为什么有的回调传窄类型没报错这个问题在社区里被问过很多次。理论上(dog: Dog)void不能赋值给(animal: Animal)void但很多人实际代码里没报错。常见原因有四个一是没有开strictFunctionTypes编译器默认宽进宽出二是目标类型是接口或 class 的方法声明双变兜底三是第三方定义把回调参数写成了any四是事件类 API 使用了泛型映射比如 addEventListener事件类型被具体化了表面上的“宽类型”只是类型定义细节。想验证到底是哪种将 tsconfig 的 strict 开起来再把方法签名改成属性签名大部分问题会立刻暴露。如果一个项目已经有大量方法声明建议用 ESLint 的 method-signature-style 规则自动改成属性签名。这个改动最大的风险是编译报错数量会一下子变多但每一处报错都接近一个潜在的运行时 bug值得花时间消化。5.3 数组为什么是协变的安全吗数组是另一个经常被问到的变型案例。TS 允许Dog[]赋值给Animal[]这是一种协变。为什么不是不变因为如果不变Dog[]就不能传给任何声明为Animal[]的参数那let animals: Animal[] dogs这种特别直观的写法就会直接报错让 TS 用起来很拧巴。于是 TS 选择让数组对于读取操作保持协变同时接受写入操作可能带来的风险。风险是什么意思let animals: Animal[] dogs; animals.push(new Cat());在类型检查上是合法的但在运行时真实数组是 Dog[]却混入了一只 Cat。这就是协变数组的经典缺口。所以我的建议是函数参数里尽量用ReadonlyArrayT或者用Dog[]传入Animal[]时不要在函数内执行任何 push、splice 这类写操作。如果你确实要在函数里写数组就保持调用方类型和参数类型一致不要再做父类型接收。最后分享一个我平时排查变型问题的土办法在报错行上方临时给两个函数类型各起一个别名比如type A (animal: Animal)void; type B (dog: Dog)void;然后把它们拖进declare let a: A; let b: B; a b;去试。报错会更直接而且不会受调用上下文干扰。多玩几次之后你会彻底习惯“参数宽、返回值窄”这个方向。协变和逆变不是冷门考点它藏在Array.map、事件总线、泛型工具类型这些日常代码的每一个角落。