TypeScript接口中箭头函数与普通函数类型推断误判致运行时错误

问题现象 #

我遇到了TypeScript里两种接口属性类型的赋值行为不一致的问题，具体表现为：

• (1) 将仅支持string类型参数的普通函数赋值给要求处理string | undefined的接口方法属性时，TypeScript未报错，但运行时传入undefined调用会出错；
• (2) 将仅支持string类型参数的箭头函数赋值给要求处理string | undefined的箭头函数类型接口属性时，TypeScript能正确报错；
• (3) 将仅支持string类型参数的箭头函数赋值给要求处理string | undefined的接口方法属性时，TypeScript同样未报错，运行时传入undefined调用也会出错。

对应的示例代码：

const arrowAcceptingString = (str: string) => "some string";
function functionAcceptingString(str: string) { return str[0] ?? "some string"; }

interface MethodCanHandleStringOrUndefined{
    handleText(text: string | undefined): string;
}

interface ArrowCanHandleStringOrUndefined {
    handleText: (text: string | undefined) => string;
}

// (1) 预期报错，但TypeScript未提示
const testMethod: MethodCanHandleStringOrUndefined = {
    handleText: functionAcceptingString
}

// (2) TypeScript正确报错 ✅
const testArrowFunction: ArrowCanHandleStringOrUndefined = {
    handleText: arrowAcceptingString,
}

// (3) 预期报错，但TypeScript未提示
const testArrowToMethod : MethodCanHandleStringOrUndefined = {
    handleText: arrowAcceptingString
}

testMethod.handleText(undefined); // 运行时错误
testArrowToMethod.handleText(undefined); // 运行时错误

核心原因：方法与函数类型的兼容性规则差异 #

TypeScript对接口中的方法类型和箭头函数类型属性采用了不同的兼容性检查逻辑，核心在于参数类型的协变/逆变规则：

1. 方法类型的双向协变（Bivariance） #

对于接口里用方法语法定义的属性（比如handleText(text: string | undefined): string），TypeScript默认启用双向协变规则。这意味着：

• 既允许将参数类型更宽泛的函数赋值给目标（协变），也允许将参数类型更严格的函数赋值给目标（逆变）。
• 这种设计是为了兼容JavaScript中常见的类方法重载场景，但会导致示例中(1)(3)的问题：严格参数类型的函数被允许赋值给宽泛参数类型的方法属性，编译时无报错，但运行时传入不符合函数参数要求的值就会出错。

2. 箭头函数类型的参数逆变（Contravariance） #

对于接口里用箭头函数语法定义的属性（比如handleText: (text: string | undefined) => string），TypeScript采用参数逆变的严格检查规则：

• 赋值的函数参数类型必须是目标参数类型的超类型（或者说，目标参数类型必须是赋值函数参数类型的子类型）。
• 示例中(2)的情况，arrowAcceptingString只接受string，而目标要求接受string | undefined，string并不是string | undefined的超类型，因此TypeScript会正确触发类型错误，避免运行时隐患。

解决方案：启用严格函数类型检查 #

如果你希望对方法类型也应用和箭头函数一致的严格检查，可以在tsconfig.json中启用--strictFunctionTypes编译选项：

{
  "compilerOptions": {
    "strictFunctionTypes": true
  }
}

启用后，示例中的(1)(3)都会触发TypeScript错误，从编译阶段就拦截潜在的运行时问题。

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