TypeScript类与个体对象通用模板搭建 类型报错问题求解

你遇到的问题和Partial<>的使用、interface和type的选型都没有关系，本质是自定义接口的命名和TypeScript内置全局类型重名，触发了TS的接口声明合并机制。

TypeScript在基础类型定义文件中本身内置了一个全局ObjectConstructor接口，用来描述全局Object构造函数的结构，包含prototype、getPrototypeOf、getOwnPropertyNames等20余个内置方法和属性。由于TS的interface天生支持声明合并——即同一作用域下同名的interface定义会自动合并所有成员，你在全局作用域下写的同名ObjectConstructor接口，会被TS自动和内置的同名接口做合并。
最终你定义的ObjectConstructor类型，变成了“包含你写的7个游戏对象属性 + 内置Object构造器的20余个属性”的交叉类型，自然在传入只带7个属性的普通对象时，会抛出“缺少20余个内置属性”的编译错误。
之前移除类上的implements语句能正常跑，只是因为此时没有触发完整的类型校验链路，并没有从根源解决类型冲突的问题。

从根上避免命名冲突即可，不需要额外调整类型定义的关键字：

• 把自定义接口换成一个和全局内置类型不重名的名称，比如GameObjectConfig，从源头切断和内置类型的声明合并路径
  调整后的代码示例：

  // 重命名为无冲突的接口名
  interface GameObjectConfig {
      element: HTMLElement;
      x_pos: number;
      y_pos: number;
      x_velocity: number;
      y_velocity: number;
      ele_width: number;
      ele_height: number;
  }
  
  abstract class GameObject implements GameObjectConfig {
      element: HTMLElement;
      x_pos: number;
      y_pos: number;
      x_velocity: number;
      y_velocity: number;
      ele_width: number;
      ele_height: number;
  
      constructor(config: GameObjectConfig) {
          this.element = config.element;
          this.x_pos = config.x_pos;
          this.y_pos = config.y_pos;
          this.x_velocity = config.x_velocity;
          this.y_velocity = config.y_velocity;
          this.ele_width = config.ele_width;
          this.ele_height = config.ele_height;
      }
  }
  

• 同步把PlayerPrototype的类型标注换成新的接口名：

  let PlayerPrototype: GameObjectConfig = {
      element: document.createElement("div"),
      x_pos: Game.bodyWidth/2 - 30,
      y_pos: Game.bodyHeight - 50,
      x_velocity: Game.properites.player_speed,
      y_velocity: Game.properites.player_speed,
      ele_width: 30,
      ele_height: 50
  };
  

调整完成后，原有编译错误会直接消失，且能完整保留接口对类结构、入参类型的约束能力。

• 为什么不需要改用type定义类型别名？
  就算把当前的interface换成type定义，只要命名还是ObjectConstructor，依然会在全局作用域和内置类型产生冲突，且type定义重名时会直接抛出重复标识符错误，完全解决不了现有问题。
• 为什么不需要使用Partial<>工具类型？
  Partial<>的作用是把接口的所有必填属性转为可选，适配的是“部分传参、配置合并”的场景。你当前的场景是要求游戏对象初始化的所有参数必须完整传入，使用Partial<>反而会弱化类型校验能力——比如漏传核心的element属性时，TS不会再给出报错，完全违背你用接口做约束的初衷。

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