TypeScript泛型函数类型不兼容及扩展接口返回类型优化咨询

首先咱们先拆解第一个泛型写法报错的原因：

当你定义getObject<T extends Base>(id): T时，TypeScript会认定T可以是任意继承自Base的类型——比如你已经定义的B类型，它只要求包含prop1和propB，但你函数里返回的对象带的是propA，这显然和B的结构不兼容。TS无法保证你返回的固定结构能匹配所有可能的T，所以会抛出类型不兼容的错误。

而改成返回A | B虽然能暂时运行，但确实像你说的，后续新增C、D这类Base子类时，必须手动更新联合类型，维护成本极高，完全违反了开闭原则。下面给你两个更优的解决方案：

方案一：让调用者提供对象工厂函数（最推荐） #

既然函数内部无法预知T的具体结构，不如把创建T实例的逻辑交给调用者。这样函数只负责传递必要参数（比如这里的id），完全不用关心具体要返回哪个子类：

interface Base { prop1: any; }
interface A extends Base { propA: string; }
interface B extends Base { propB: string; }

class YourClass {
  public getObject<T extends Base>(id: any, factory: (id: any) => T): T {
    return factory(id);
  }
}

// 调用示例
const instance = new YourClass();
// 获取A类型对象
const objA = instance.getObject(123, (id) => ({ prop1: id, propA: '2' }));
// 获取B类型对象
const objB = instance.getObject(456, (id) => ({ prop1: id, propB: 'hello' }));
// 新增C类型时，直接调用传对应工厂即可，无需修改getObject函数
interface C extends Base { propC: number; }
const objC = instance.getObject(789, (id) => ({ prop1: id, propC: 100 }));

这种方式完全解耦了函数和具体子类，新增子类时零修改原函数，扩展性拉满，而且TS能完美推导返回的具体类型。

方案二：使用类型断言结合Base基础结构（谨慎使用） #

如果你确实不想让调用者传工厂函数，且能保证返回的对象至少符合Base的结构，同时愿意承担一定的类型安全风险，可以用类型断言。但要注意：这种方式下TS不会帮你校验返回对象是否真的符合T的结构，需要你自己保证逻辑正确：

class YourClass {
  public getObject<T extends Base>(id: any): T {
    // 返回Base的基础结构，调用者可根据需求扩展属性
    return { prop1: id } as T;
  }
}

// 调用示例
const objA = instance.getObject<A>(123);
objA.propA = '2'; // 需手动补充A类型的专属属性

不过这种方式局限性很明显：如果T要求的属性不止Base的内容，你要么手动后续赋值，要么在函数里提前预判所有可能的属性，这又回到了扩展性差的问题。所以除非你的场景非常简单，否则更推荐方案一。

总结来说，方案一通过工厂函数把创建逻辑交给调用者，完美平衡了类型安全和扩展性，是最符合TypeScript设计理念的解决思路。

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