TypeScript同名泛型接口继承报错：求替代方案或是否需更名

首先得明确：TypeScript的接口设计和C#有本质区别——C#是名义类型系统，同名但泛型参数不同的接口会被视为完全独立的类型；但TS是结构类型系统，同名接口会自动合并，这就要求所有同名接口的类型参数必须完全一致，所以你遇到的All declarations of IThing must have identical type parameters报错是TS的设计限制。

不过也不是只能被迫改名，下面给你两种可行的方案，你可以根据业务场景选择：

方案1：使用不同的接口名称（最推荐） #

这是TS社区最常用也最清晰的做法，直接给泛型和非泛型接口起差异化的名字，既符合TS规范，又能和C#里的继承逻辑保持对齐：

// 非泛型基础接口
interface IThing {
  id: string;
}

// 泛型接口继承非泛型接口
interface IThing<T> extends IThing {
  process(value: T): void;
}

这种写法没有任何类型歧义，代码可读性拉满，是绝大多数场景下的最优解。

方案2：用可选泛型参数模拟“双接口”行为 #

如果你坚持不想改名，可以让泛型接口的类型参数设为可选默认值，把两个接口的逻辑合并到同一个接口里：

// 泛型参数默认值设为void，模拟非泛型场景
interface IThing<T = void> {
  // 非泛型接口的公共属性/方法
  id: string;
  // 仅当传入泛型参数时才启用的泛型方法，用条件类型限制
  process?: T extends void ? never : (value: T) => void;
}

// 非泛型使用方式
const basicThing: IThing = { id: "item-1" };

// 泛型使用方式
const genericThing: IThing<number> = {
  id: "item-2",
  process: (val) => console.log(`Processing number: ${val}`)
};

这种方式的本质是用同一个接口兼容两种场景，但要注意：它并不是真正的“继承”关系，只是通过条件类型让泛型方法在非泛型场景下不可用。如果你的业务逻辑里两个接口的差异很大，这种写法会让接口变得复杂，反而不如方案1直观。

为什么TS不支持C#的写法？ #

补充下底层逻辑：TS的接口合并机制是为了让你可以分散定义同一个接口的不同部分（比如从不同文件导入后合并），但如果允许同名接口有不同的泛型参数，合并后的类型会出现歧义——结构类型系统无法区分“同名但泛型参数不同”的接口，所以TS直接禁止了这种写法。

总结下来，方案1（改名）是最稳妥且符合TS最佳实践的选择，方案2只适合简单场景下的兼容需求。

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