React JS中函数组件两种TypeScript类型标注方式有何区别？

两种写法运行结果完全一致是正常的。TypeScript的类型标注只在编译阶段做类型校验，所有类型标记在编译为JavaScript代码后都会被完全擦除，不会进入运行时逻辑，自然不会影响实际执行结果。二者的区别仅存在于TypeScript类型检查环节：

仅在React.FC泛型传入Props的写法 #

const Result: React.FC<ResultProps> = ({ prop1, prop2 }) => {

这是符合TypeScript设计逻辑的常规写法：你已经通过类型标注明确告诉TS，Result是一个接收ResultProps类型参数的React函数组件，TS会通过上下文类型推导能力，自动给函数入参匹配ResultProps类型，解构得到的prop1、prop2都会自动拿到对应属性的类型，绝大多数场景下类型检查可以正常工作，不存在类型遗漏。

参数位置重复标注Props的写法 #

const Result: React.FC<ResultProps> = ({ prop1, prop2 }: ResultProps) => {

这种写法本质属于冗余标注，99%的场景下和上一种写法的类型检查效果完全一致，开发者保留这种写法主要有几个实际原因：

• 兼容旧版本TypeScript的推导缺陷：早期TS版本对箭头函数的上下文类型传递能力较弱，当函数逻辑复杂、存在泛型嵌套、类型重载等写法时，偶尔会出现类型没有正确传递到入参、导致参数被隐式推导为any的问题，在参数位置显式标注类型可以直接绕过这类推导bug。近年的TS版本已经基本修复了这类问题，这种兼容写法的必要性已经很低。
• 规避React.FC类型定义不一致的问题：不同版本的@types/react对React.FC的类型定义存在差异，比如React 17及更早的类型定义中，React.FC会默认给组件加上children?: ReactNode的属性，即使你的ResultProps里没有声明children，靠上下文推导的参数也会自带children类型；如果在参数位置显式标注ResultProps，只要Props类型里没声明children，解构children时TS就会直接抛错，能提前发现类型不匹配的问题。
• 个人编码习惯：很多开发者从TS早期版本开始使用，养成了函数入参必须显式标注类型的习惯，即使存在少量冗余也会保留写法，避免踩类型推导的偶发问题。

补充实践建议 #

目前React+TS的社区主流实践里，更推荐直接省略React.FC标注，只在参数位置标注Props类型即可：

const Result = ({ prop1, prop2 }: ResultProps) => {

这种写法既避开了不同版本React.FC类型定义不一致的坑，也没有冗余标注，类型检查的准确性最高。

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