React函数组件和class组件语法有什么区别？

一、组件声明形式与 Props 接收机制

在 React 应用程序中，两者的首要语法区别直观体现在组件外壳的定义方式，以及接收父级传入数据（Props）的语法路径。

以下是相同需求下两者的声明语法对照：

import React from 'react';

class UserInfo extends React.Component {
  render() {
    // 必须从实例属性 this.props 中获取参数
    const { name, role = '访客' } = this.props;
    return (
      <div className="user-card">
        <h3>{name}</h3>
        <p>身份：{role}</p>
      </div>
    );
  }
}

import React from 'react';

// 直接在形参列表完成解构与默认值赋值
function UserInfo({ name, role = '访客' }) {
  return (
    <div className="user-card">
      <h3>{name}</h3>
      <p>身份：{role}</p>
    </div>
  );
}

从语法层面上看，函数组件省去了类的实例化仪式和 render 方法包裹，代码行数明显减少。更重要的是，在 TypeScript 开发环境下，函数组件只需针对函数参数标注类型（如 function UserInfo(props: UserProps)），而 Class 组件则需要通过繁复的泛型参数 React.Component<UserProps, UserState> 进行约束，类型声明负担重得多。

二、状态（State）声明与更新机制的差异

在 React 16.8 引入 Hooks 之前，函数组件被称为“无状态组件（Stateless Component）”，仅负责接收 Props 进行展示渲染。而随着 useState 的出现，函数组件获得了完备的状态管理能力，两者在状态的声明语法和更新机制上存在质的差异。

1. 状态初始化的语法位置

在 Class 组件中，状态是集中挂载在实例属性 this.state 上的单一复合对象。初始化通常在构造函数 constructor(props) 内完成，或者使用现代类的公共属性字段语法：

class Counter extends React.Component {
  // 类属性字段声明
  state = {
    count: 0,
    text: '',
    loading: false
  };
}

而在函数组件中，状态通过调用 useState 钩子细粒度声明。每一次调用 useState 都会返回一个包含当前状态值与对应 Setter 更新函数的双元素数组：

function Counter() {
  // 细粒度、按关注点解耦的独立状态
  const [count, setCount] = useState(0);
  const [text, setText] = useState('');
  const [loading, setLoading] = useState(false);
}

2. 状态更新行为：浅合并 vs 全量覆盖

状态更新的核心语法区别在于：Class 组件的 this.setState() 具备自动浅合并（Shallow Merge）特性，而函数组件的 Setter 则是全量替换。

• Class 组件：当你调用 this.setState({ count: 1 }) 时，React 只会覆盖 state 对象中的 count 属性，而 text 和 loading 依然保留。
• 函数组件：若 useState 中存放的是一个对象，调用更新函数时传入的新值会整体替代旧对象。如果未显式展开剩余属性，其他字段将会丢失。

// Class 组件：自动合并，其他未传递字段不受影响
this.setState({ name: 'Bob' });

// 函数组件：必须手动利用展开运算符保留其余字段
setUser(prevUser => ({
  ...prevUser,
  name: 'Bob'
}));

三、生命周期函数与副作用 (useEffect) 的思维转换

Class 组件与函数组件在处理“数据请求、订阅发布、手动操作 DOM、定时器”等副作用行为时，采用了完全不同的语法组织维度。

1. Class 组件的按生命周期阶段切分

Class 组件遵循经典的组件生命周期模型，开发者必须将代码拆散到特定的生命周期方法中：

• componentDidMount()：DOM 挂载完成后执行，常用于发起初次 API 请求、开启定时器或建立 WebSocket 订阅。
• componentDidUpdate(prevProps, prevState)：Props 或 State 改变导致重新渲染后触发，开发者必须在此手动编写条件判断（如 if (prevProps.userId !== this.props.userId)）以防止死循环更新。
• componentWillUnmount()：组件销毁前调用，负责清理定时器、注销事件监听与断开连接。

这种模式的一个典型弊端是相关联的逻辑被强制割裂。例如设置定时器必须写在 componentDidMount，而清除该定时器必须写在 componentWillUnmount，相隔甚远；同时，互不相干的数据获取逻辑与事件监听逻辑却不得不塞进同一个钩子函数中，极易形成维护隐患。

2. 函数组件的按业务关注点组合 (useEffect)

函数组件废弃了阶段性的生命周期方法，统一由 useEffect 表达副作用。一个 useEffect 内部即可完整涵盖“建立”与“清理”两道工序：

function UserProfile({ userId }) {
  const [profile, setProfile] = useState(null);

  useEffect(() => {
    let isCancelled = false;

    // 1. 副作用逻辑：发起请求
    fetchUserData(userId).then(data => {
      if (!isCancelled) setProfile(data);
    });

    // 2. 清理函数：在组件重新同步或卸载时触发
    return () => {
      isCancelled = true;
    };
  }, [userId]); // 3. 依赖项数组：仅当 userId 变化时重新运行
}

如上图所示，useEffect 不仅在语法上将设置与清理闭环封装在同一个代码块内，还允许在单个组件内部根据业务职责书写多个独立的 useEffect。这实现了逻辑上的高度内聚与相互隔离。

四、事件处理机制：this 绑定与闭包渲染快照

在交互事件编写中，Class 组件与函数组件展现出了截然不同的语言层底层机制：前者受制于 JavaScript 的动态 this 绑定规则，后者则深度依赖函数的词法作用域闭包与渲染快照。

1. Class 组件中 this 的丢失与应对方案

在 Class 组件中，类方法并不会默认绑定当前类实例。如果将一个普通的类原型方法直接传递给 JSX 的 onClick 事件，在事件被触发时，由于上下文改变，方法内部的 this 将会变为 undefined，导致调用 this.setState 时直接抛出运行时错误。

社区常见的语法解决手段有两种：

1. 在构造函数中显式绑定：this.handleClick = this.handleClick.bind(this);（代码冗长繁琐）。
2. 使用类公共字段定义箭头函数：handleClick = () => { ... };（语法简洁，目前最为普遍）。

2. 运行时差异：可变实例引用 vs 闭包渲染快照

除了书写繁琐之外，this 机制还隐藏着深层次的数据时序 Bug。React 团队曾通过著名的延时提示示例指出：Class 组件的 this.props 和 this.state 始终是指向活体实例的可变引用（Mutable Reference）。

class MessageClass extends React.Component {
  showMessage = () => {
    // 异步 3 秒后读取 this.props.user
    setTimeout(() => {
      // 3 秒后组件实例上的 this.props 可能已经被父组件更改！
      alert('已关注: ' + this.props.user);
    }, 3000);
  };

  render() {
    return <button onClick={this.showMessage}>关注</button>;
  }
}

如果在点击按钮后的 3 秒内，父组件将 user 从 "张三" 切换为 "李四"，3 秒后的弹窗将会显示“已关注: 李四”，这违反了用户点击关注那一瞬间的操作预期。

相反，在函数组件中，每一次渲染都是一次完全隔离的函数调用。函数组件的入参 props 和内部变量是固定在该次调用作用域内的局部常量。

function MessageFunction({ user }) {
  const showMessage = () => {
    setTimeout(() => {
      // 闭包牢牢捕获了点击发生时那一次渲染中的 user 快照
      alert('已关注: ' + user);
    }, 3000);
  };

  return <button onClick={showMessage}>关注</button>;
}

五、实操指引：将 Class 组件平滑重构成函数组件的步骤

在实际项目维护中，将既有的 Class 组件重构成现代函数组件是一项常见任务。以下是经过生产检验的标准五步迁移路径：

步骤一：转换外壳骨架

删除 class ... extends React.Component 语法，声明为普通函数 function ComponentName(props)。将原来的 render() 函数体直接作为函数组件的返回内容，解构所需参数。

步骤二：解耦拆分 State

检查原组件的 this.state 对象。针对不同业务意图的字段，使用独立的 useState 声明进行替换。将所有 this.setState(...) 调用替换为对应的 Setter 函数。

步骤三：整合迁移生命周期

梳理 componentDidMount、componentDidUpdate 和 componentWillUnmount 中的逻辑。将涉及同一数据源的挂载与更新动作合并为一个 useEffect，并在该 Hook 的返回函数中执行销毁时的清理逻辑。

步骤四：清除 this 依赖

全局移除 this. 前缀；删除构造函数中多余的 .bind(this)。将类成员方法直接写为函数组件内的局部函数。对于需要作为 Props 传递给被 React.memo 包裹的子组件的回调函数，可按需使用 useCallback 进行包裹。

步骤五：依赖验证与回归测试

确认所有 useEffect 与 useCallback 的依赖数组完整覆盖了引用的响应式数据，验证是否存在无意义的死循环请求或数据闭包陈旧问题，确保行为与原组件保持完全一致。

六、组件选型与历史兼容决策

在明确了语法与运行时的差异后，日常业务开发中应当如何做出合理的架构选型？

1. 必须使用 Class 组件的唯一现存场景：错误边界 (Error Boundary)

截至目前，React 官方仍未提供用于捕获子组件树渲染阶段 JavaScript 异常的 Hook 等价物。想要在应用中捕获子组件崩溃并展示降级 UI，依然必须依靠实现了 componentDidCatch 或 static getDerivedStateFromError 的 Class 组件：

class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    logErrorToService(error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      return <h2>页面出现异常，请稍后重试。</h2>;
    }
    return this.props.children;
  }
}

在实际工程中，团队通常只需在项目最外层维护一个通用的 Class 错误边界组件（或直接引入社区成熟的 react-error-boundary 库），内部业务组件则全量采用函数组件。

2. 新功能无条件首选函数组件

除上述错误边界之外，所有新创建的业务页面、基础 UI 组件以及通用逻辑封装，均应无条件选用函数组件配合 Hooks。这不仅是 React 官方团队的绝对主流指引，也是现代前端生态库（如 React Router v6+、TanStack Query、Zustand 等）全面拥抱的标准形态。

3. 老旧遗留 Class 组件的维护原则

React 官方始终保持着优良的向后兼容性，至今未弃用 Class 组件语法。因此，对于项目中运转良好、无迭代需求的历史 Class 组件，没有必要为了重构而重构。只有当该组件面临复杂的业务迭代、需要抽离跨组件共享的 Custom Hook，或者原有的 this 异步时序问题暴露出 Bug 时，再按上述五步法逐步迁移为函数组件最为稳妥。

七、总结

React 从 Class 组件走向函数组件，表面上看是去除了 class、extends、render 以及 this.bind 等大量繁琐的模板语法，实质上是推动组件开发从面向对象状态机向纯函数式渲染模型（UI = f(data)）的认知升维。

掌握这一系列语法区别的关键，在于理解函数组件中每一次渲染的独立快照特性，以及 Hooks 将状态与副作用按关注点解耦组合的强大能力。在日常工程实践中，除顶层错误边界外，坚持采用函数组件开发将带来更精简的代码量、更优雅的逻辑复用体验以及更出色的类型安全保障。