React.FC<Props>与直接定义Props的组件差异及使用咨询

你观察得很准——编译后的JS代码确实没区别，但在TypeScript的类型层面，这两种写法还是有不少关键差异的，而且第二种写法在社区里其实相当流行：

1. 隐式的children处理 #

React.FC<Props>是React官方提供的泛型类型，它会自动给你的组件props加上一个可选的children属性（类型为React.ReactNode | undefined），哪怕你定义的Props里完全没提到children。

而第二种写法（(props: Props) => ...）则严格遵循你定义的Props接口——如果你的接口里没声明children，TypeScript会直接阻止你在组件里传入子元素，也不允许在组件内部访问props.children。

很多开发者更偏爱第二种写法，就是因为它避免了这种“隐式注入”，让组件的props完全显式可控，不会出现意外接收子元素的情况。

2. 返回值的类型约束 #

React.FC会强制组件的返回值必须是React.ReactElement | null，如果你不小心返回了undefined或者其他非React元素的类型，TypeScript会立刻报错。

第二种写法的返回值则是TypeScript自动推断的——如果你的组件逻辑里有可能返回非React元素的内容，TypeScript可能不会及时提醒你，除非你手动给函数加上返回类型注解（比如const PrintName2 = (props: Props): React.ReactElement => ...）。

3. 社区使用现状 #

第二种写法现在非常普遍，尤其是在React 17版本之后，很多团队都开始放弃React.FC：

• 它更简洁，没有额外的泛型语法包裹，代码可读性更高，就像你感受到的那样。
• 避免了React.FC带来的隐式children问题，符合“显式优于隐式”的编程原则。
• 对于一些复杂的组件场景，直接定义props类型的写法也更灵活，比如需要自定义函数参数解构的类型时，不会被React.FC的泛型约束限制。

顺便提一句：你代码里的props.priority其实在两种写法里都会触发TypeScript报错，因为你的Props接口里没有定义这个属性——记得把它加上，比如改成：

interface Props { 
  name: string;
  priority?: boolean; // 声明为可选属性
}

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