通常constructor本身不应该变得“非常难看”，因为类型可以单独定义，type或者interface在参数类型冗长的情况下。

props无法推断构造函数参数，因为React.Component<RouteComponentProps<{ tag: string }>>泛型参数是指父类React.Component，而不是当前类。

正如在类型定义中所见，这推断出父构造函数的正确类型，即super.

所以这

constructor(props) {
    super(props);
}

已验证。this.props仍然正确键入。

如果使用noImplicitAny编译器选项，则为：

constructor(props: any) {
    super(props);
}

在构造函数中使用propstyped asany可能会导致类型错误：

constructor(props: any) {
    super(props);

    props.tag; // ok
    props.nonexistentProp; // ok
}

Whilethis.props是类型安全的。

一个类可以被定义为泛型以在构造函数中维护正确的 props 类型，但这可能被认为是矫枉过正：

export class PeopleByTag<P extends { tag: string }> extends React.Component<P> {
  constructor(props: Readonly<P>) {
    super(props); // props is any

    props.tag; // ok
    props.nonexistentProp; // not ok
    props.children; // not ok, but we rarely ever need children in constructor
  }
}

props通过为它提供不兼容的类型来防止在构造函数中使用它可能是有益的：

constructor(props: never) {
    super(props);

    props.tag; // not ok
}

如果props参数传递给super,this.props并且props在 JavaScript 中可以互换。它们在 TypeScript 中不可互换。this.props可以在构造函数中访问正确类型的props。

正如estus所说，我建议定义接口或类型别名以减少重复。但是请注意，props构造函数的参数类型可以是Readonly<RouteComponentProps<{ tag: string }>>，因为 TypeScript 编译器会children根据 in 中的声明自动添加属性，@types/react并且您可以依赖第二个和第三个类型参数的默认值 to RouteComponentProps，就像您在扩展条款。（可以说，如果构造函数的参数是真正的 props 对象，那么它的类型应该包括children属性，省略children属性是假的，但省略是常见的做法，甚至出现在React.Component超级构造函数的声明中。我也省略了Readonly 在一个项目中，但似乎不再值得推荐。）在这一点上，也许您会决定类型足够短，重复它是可以的，并且不值得定义接口或类型别名。

顺便说一下，这里是方法和构造函数参数类型默认为超类类型的公开建议。