类组件 vs 函数组件

	函数组件	类组件
基本语法	纯 JavaScript 函数，无 this 绑定	ES6 类语法，需处理 this 绑定
状态管理	useState / useReducer，细粒度控制，不可变状态	this.setState，批量更新，可变状态对象
生命周期	useEffect 统一管理副作用，逻辑聚合	显式生命周期方法（componentDidMount 等），逻辑分散
代码复杂度	更简洁（减少约 40% 样板代码）	需要 constructor / super 等固定结构
性能优化	React.memo + useMemo / useCallback	shouldComponentUpdate + PureComponent
错误边界	❌ 无法直接实现	✅ 唯一实现方式（componentDidCatch）
逻辑复用	自定义 [[03 - 前端 Frontend/React 框架 React Framework/Hooks	Hooks]]（天然组合式复用）
TS 支持	更好的类型推断（Props 直接作为函数参数）	需要声明 Component<Props, State> 泛型
内存占用	更优（无类实例开销）	较高（每个组件生成类实例）
现代特性支持	✅ 完整支持并发模式/Server Components	❌ 部分特性受限（如 Suspense 数据获取）
典型应用场景	- 90%+ 新组件开发 - 复杂状态逻辑（结合 Context/Redux） - 需要逻辑复用的模块	- 错误边界组件 - 维护遗留代码 - 需要精确控制生命周期
调试难度	更易追踪状态变化（闭包环境）	this 上下文问题常见（需绑定方法）
测试友好度	纯函数更易单元测试	需要处理类实例和生命周期
未来兼容性	React 官方推荐方向，持续获得新特性	功能冻结，仅维护模式

关键差异场景

场景	函数组件方案	类组件方案
数据请求 +loading	useEffect + useState 集中管理	componentDidMount + 分散状态更新
表单处理	useForm 自定义 Hook	手动处理多个 setState
性能优化	React.memo + useMemo	shouldComponentUpdate 深度比较
全局状态	useContext + useReducer	高阶组件包裹 + 手动订阅
动画控制	useEffect 清理副作用 + requestAnimationFrame	componentDidMount / componentWillUnmount 管理