TypeScript接口逆变问题：非类型安全实现的合理性疑问

我发现TypeScript中存在一个类型安全漏洞：当类实现接口时，方法可以使用比接口要求更具体的参数类型，导致运行时可能抛出异常，但编译器不会报错。示例代码如下：

interface Point {
  x: number;
  y: number;
  dist(other: Point): number
}

class GridPoint implements Point {
  constructor(public x: number, public y: number) {}
  dist(other: Point) { /* 数学计算逻辑 */ }
}

class NamedPoint implements Point {
  constructor(
    public x: number,
    public y: number,
    public name: string
  ) {}

  dist(other: NamedPoint) {
    // 这里访问other.name，但并非所有Point都有该属性
    if (other.name.startsWith('')) { /* ... */ }
    return 0; // 示例返回值
  }
}

// 运行时会抛出异常，但编译器无报错
function getDist(a: Point, b: Point) {
  console.log(`distance is: ${a.dist(b)}`)
}
getDist(new NamedPoint(1, 2, 'foo'), new GridPoint(9, 8));

原本以为开启strictFunctionTypes可以解决这个问题，但似乎不适用此场景。想知道这是我对类型系统的理解有误，还是TypeScript的设计问题？如果是后者，有什么解决办法？

原因分析 #

1. 类方法与函数类型的检查差异
   TypeScript中，类实现接口时的方法参数默认采用协变检查，而非函数类型的逆变检查。即使开启strictFunctionTypes，也只会影响独立函数类型的赋值检查，不会改变类方法的检查规则。这是TS为了兼容大量现有代码而做出的设计权衡——如果强制类方法参数逆变，很多既有代码会出现编译错误。

2. 结构类型系统的特性
   TS基于结构类型系统判断兼容性：NamedPoint是Point的子类型，所以TS认为接受NamedPoint的方法，也能兼容接受Point的接口定义。但实际上这种协变是不安全的，因为当传入父类型Point（比如GridPoint）时，方法内部访问子类型特有的属性（如name）会导致运行时错误。

解决办法 #

1. 强制方法参数与接口保持一致 #

让NamedPoint的dist方法参数严格遵循接口定义的Point类型，在方法内部通过类型守卫处理子类型的特殊逻辑：

class NamedPoint implements Point {
  // ... 构造函数省略
  dist(other: Point) {
    if (other instanceof NamedPoint) {
      // 类型守卫确保此处other是NamedPoint，可安全访问name
      if (other.name.startsWith('')) { /* ... */ }
    }
    // 通用的Point距离计算逻辑
    return Math.hypot(this.x - other.x, this.y - other.y);
  }
}

2. 将接口中的方法改为函数类型 #

如果把接口里的dist定义为函数类型而非方法，开启strictFunctionTypes后就会触发逆变检查，阻止不安全的实现：

interface Point {
  x: number;
  y: number;
  dist: (other: Point) => number; // 函数类型
}

class NamedPoint implements Point {
  // ... 构造函数省略
  dist: (other: Point) => number = (other) => {
    // 必须接受Point类型，否则编译报错
    if (other instanceof NamedPoint) { /* ... */ }
    return Math.hypot(this.x - other.x, this.y - other.y);
  };
}

3. 启用完整的严格模式 #

开启strict: true（包含所有严格检查选项），虽然不能直接解决这个问题，但能减少其他潜在的类型安全隐患，同时配合上述方法从根源避免此类问题。

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