在 React + TypeScript 项目中，React.FC（即 React.FunctionComponent 的别名）曾经是定义函数组件的常见方式，但如今社区普遍推荐避免使用它，转而直接注解组件的 props 类型。下面我一步步解释原因和演变过程。

历史背景和早期问题

早期（React 17 及更早版本结合旧 TypeScript 时），React.FC 被广泛使用，因为它提供了一种简便的类型注解方式，能自动推断一些静态属性如 displayName、propTypes 和 defaultProps。然而，它存在几个显著缺点：

• 隐式 children prop：React.FC 会自动将 children 添加到 props 类型中，即使组件不需要它。这会导致类型不准确，例如如果你定义一个不接受 children 的组件，用户仍能传入 children 而不会报错。

  
  

• 泛型支持不佳：使用 React.FC 时，泛型组件的类型定义变得复杂且不易读。

  
  

• defaultProps 问题：与 defaultProps 结合时，可能出现类型不兼容或推断错误。

  
  

• 返回类型限制：React.FC 强制返回 React.ReactElement，不允许直接返回 null、string、number 或其他类型，这在某些场景下不灵活。

  
  

• 函数类型应用困难：React.FC 本质上是函数类型，难以直接应用于命名函数，导致代码更冗长。

  
  

这些问题导致社区（如 Create React App 在 2020 年移除对 React.FC 的默认使用）开始转向其他方式。 许多知名开发者、TypeScript 贡献者和框架（如 Backstage）也公开不推荐它。

// 旧方式（不推荐）
const MyComponent: React.FC<{ name: string }> = ({ name }) => <div>Hello, {name}</div>;


// 新方式（推荐）
function MyComponent({ name }: { name: string }) {
  return <div>Hello, {name}</div>;
}


// 或箭头函数
const MyComponent = ({ name }: { name: string }) => <div>Hello, {name}</div>;


// 如果需要 children 或其他复杂类型
type Props = {
  name: string;
  children?: React.ReactNode; // 显式添加，如果需要
};
function MyComponent({ name, children }: Props) {
  return <div>{name}{children}</div>;
}