TypeScript何时使用结构类型？及相关类型赋值合规性疑问

一、TypeScript使用结构类型的常见场景 #

TypeScript作为结构类型系统，核心逻辑是「基于类型的形状（结构）而非名称判断兼容性」，主要在这些场景下生效：

• 对象/接口类型：只要两个对象的属性（名称、类型、可选性）完全匹配，即使定义名称不同，也会被视为兼容
• 类实例类型：默认按结构检查——两个类的实例只要结构一致，哪怕来自不同类也能互相赋值；但如果类包含private或protected成员，会切换为名义类型检查，只有同类（或子类）实例才兼容
• 函数类型：函数兼容性基于参数逆变、返回值协变，只看参数列表和返回值的结构，不关心函数名称或定义位置
• 联合/交叉类型的成员兼容性：判断联合类型赋值时，会检查源类型的每个成员是否能匹配目标类型的某一个成员，这里同样依赖结构类型判断

二、你的Result类型赋值问题详解 #

先回顾你给出的原始代码：

class Success<S> {
  constructor(public value: S) { }
  static create<S, F>(value: S):Result<S, F> {
    return new Success<S>(value);
  }
}
class Failure<F> {
  constructor(public value: F) {}
  static create<S, F>(value: F): Result<S, F> {
    return new Failure<F>(value);
  }
}
type Result<S, F> = Success<S> | Failure<F>;

// 为何编译器允许这个赋值？
const f: Result<number, Error> = Failure.create(2);

问题根源 #

当调用Failure.create(2)时，TypeScript的类型推断逻辑是：

• F被推断为number（因为传入的value是数值2）
• S没有任何约束，默认推断为unknown
  因此Failure.create(2)的返回类型是Result<unknown, number>，也就是Success<unknown> | Failure<number>。

编译器允许它赋值给Result<number, Error>的核心原因是：Success<S>和Failure<F>的结构完全一致——两者都只有一个public value属性。在结构类型系统下，TypeScript认为Failure<number>和Success<number>是兼容的（形状完全匹配），而Success<number>是Result<number, Error>的成员之一，所以整个赋值操作被允许。你猜测的「结构类型导致类型可互换」是完全正确的。

三、你的Symbol方案分析与验证 #

你提出的通过添加唯一Symbol属性区分两个类的方案非常优雅，既保持了value接口的一致性，又完美解决了结构类型导致的兼容性问题：

export const SuccessType = Symbol();
export class Success<S> {
  public readonly resultType = SuccessType;
  private constructor(public value: S) {}
  static create<S, F>(value: S): Result<S, F> {
    return new Success<S>(value);
  }
}
export const FailureType = Symbol();
export class Failure<F> {
  public readonly resultType = FailureType;
  private constructor(public value: F) {}
  static create<S, F>(value: F): Result<S, F> {
    return new Failure<F>(value);
  }
}

方案为什么有效？ #

• 唯一Symbol制造结构差异：Success的resultType是typeof SuccessType，Failure的是typeof FailureType，而Symbol()创建的是全局唯一值，TypeScript会将这两个属性视为不同类型，让Success<S>和Failure<F>的结构不再等价
• readonly+私有构造函数增强安全性：readonly确保外部无法修改resultType，私有构造函数限制只能通过create方法创建实例，避免手动创建实例破坏类型约束

这个方案没有问题，是解决「需要名义类型但想保持结构一致」场景的最佳实践之一。

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