Frontend►React

001-React生命周期

以下是React生命周期的详细解析，包含具体应用场景、变更原因及图示说明，基于React 17/18版本（截至2025年6月）。

一、React生命周期全阶段图解与说明

新版生命周期流程图（React 16.4+）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
graph TD
A[挂载阶段] --> B(constructor)
B --> C{static getDerivedStateFromProps}
C --> D(render)
D --> E(componentDidMount)

F[更新阶段] --> C
C --> G{shouldComponentUpdate}
G -->|true| D
D --> H(getSnapshotBeforeUpdate)
H --> I(componentDidUpdate)

J[卸载阶段] --> K(componentWillUnmount)

L[错误处理] --> M(static getDerivedStateFromError)
M --> N(componentDidCatch)

二、各阶段详解与应用场景

1. 挂载阶段（Mounting）

  • constructor()

    • 场景：初始化state（如表单默认值）、绑定事件方法
    • 示例：
      1
      2
      3
      4
      5
      constructor(props) {
        super(props);
        this.state = { count: 0 };
        this.handleClick = this.handleClick.bind(this);
      }

  • static getDerivedStateFromProps(props, state)

    • 场景：props变化时同步state（如分页组件接收外部页码参数）
    • 限制：必须是纯函数，无副作用
    • 示例：
      1
      2
      3
      static getDerivedStateFromProps(props) {
        return { page: props.initialPage }; // 用props初始化state
      }

  • render()

    • 规则：返回JSX，禁止执行setState或操作DOM

  • componentDidMount()

    • 核心场景：
      1. 数据请求（AJAX/Fetch）
      2. DOM操作（集成D3.js图表）
      3. 订阅事件（WebSocket监听）
    • 示例：
      1
      2
      3
      4
      componentDidMount() {
        fetch('/api/data').then(res => this.setState({ data: res.data }));
        this.timer = setInterval(() => this.tick(), 1000);
      }

2. 更新阶段（Updating）

  • shouldComponentUpdate(nextProps, nextState)

    • 场景：性能优化（阻止不必要的渲染）
    • 示例：
      1
      2
      3
      shouldComponentUpdate(nextProps) {
        return nextProps.userID !== this.props.userID; // 仅当userID变化时重渲染
      }

  • getSnapshotBeforeUpdate(prevProps, prevState)

    • 场景：DOM更新前捕获状态（如滚动位置保持）
    • 经典案例：聊天窗口新消息插入时保持视图位置
      1
      2
      3
      4
      5
      6
      7
      getSnapshotBeforeUpdate() {
        return this.listRef.scrollHeight; // 返回更新前容器高度
      }
      componentDidUpdate(prevProps, prevState, snapshot) {
        // snapshot为更新前高度，计算差值调整滚动条
        this.listRef.scrollTop += this.listRef.scrollHeight - snapshot;
      }

  • componentDidUpdate(prevProps)

    • 场景：
      1. props变化后重新请求数据（如路由参数变更）
      2. 更新第三方库（如图表数据更新）
        1
        2
        3
        4
        5
        componentDidUpdate(prevProps) {
          if (this.props.productID !== prevProps.productID) {
            this.fetchProductData(); // ID变化时重新拉取数据
          }
        }

3. 卸载与错误处理

  • componentWillUnmount()

    • 场景：清理定时器/事件监听/取消请求
      1
      2
      3
      4
      componentWillUnmount() {
        clearInterval(this.timer);
        window.removeEventListener('resize', this.handleResize);
      }

  • 错误边界（Error Boundaries）

    • **static getDerivedStateFromError()**：渲染备用UI
    • **componentDidCatch()**：记录错误日志
    • 示例：
      1
      2
      3
      4
      5
      6
      7
      8
      9
      class ErrorBoundary extends Component {
        state = { hasError: false };
        static getDerivedStateFromError() {
          return { hasError: true }; // 触发降级UI
        }
        componentDidCatch(error, info) {
          logErrorToService(error, info); // 上报错误
        }
      }

三、生命周期变更的核心原因

1. Fiber架构的异步渲染需求

React 16引入Fiber架构以实现可中断渲染，旧生命周期（如componentWillMount）可能被多次调用，导致：

  • 资源泄露：重复创建订阅/请求
  • 状态不一致：中断后恢复时props/state不同步

2. 副作用规范化

  • 问题：componentWillMount中的异步操作可能操作未挂载的DOM
  • 解决：将副作用（数据请求等）移至componentDidMount，保证DOM就绪

3. 不安全方法的滥用

  • componentWillReceiveProps反模式：
    1
    2
    3
    4
    // 旧版：易错误同步props到state
    componentWillReceiveProps(nextProps) {
      this.setState({ value: nextProps.value }); // 破坏单一数据源
    }
    新版通过**getDerivedStateFromProps**强制纯函数解决

四、Hooks对生命周期的替代方案

函数组件+Hooks成为主流范式（React 16.8+）：

类组件生命周期 Hooks等效方案 示例
componentDidMount useEffect(..., []) 初始化请求数据
componentDidUpdate useEffect(..., [deps]) 依赖项更新后执行逻辑
componentWillUnmount useEffect返回清理函数 清除定时器/订阅
shouldComponentUpdate React.memo + useMemo 浅比较props避免重渲染
getDerivedStateFromProps useState + useEffect 根据props更新state

✅ Hooks优势：逻辑复用（自定义Hook）、无this绑定问题、代码更简洁

五、关键场景对比表

场景 类组件方案 函数组件方案
数据请求 componentDidMount useEffect + 空依赖数组
滚动位置保持 getSnapshotBeforeUpdate useLayoutEffect + ref保存位置
事件订阅/清理 componentDidMount + componentWillUnmount useEffect返回清理函数
props派生state getDerivedStateFromProps useState + useEffect监视props
错误捕获 getDerivedStateFromError 暂无直接等效（需类组件错误边界）

六、官方变更总结与最佳实践

  1. 废弃原因

    • 🚫 componentWillMount：服务端渲染可能重复调用
    • 🚫 componentWillReceiveProps：易错误同步props/state
    • 🚫 componentWillUpdate：操作DOM导致状态不一致

  2. 迁移策略

    • 新项目：函数组件 + Hooks
    • 旧项目改造：
      • 用getDerivedStateFromProps替代componentWillReceiveProps
      • 用getSnapshotBeforeUpdate替代componentWillUpdate

  3. 设计思想演进

    • 同步 → 异步：为Concurrent Mode提供中断/优先级调度能力
    • 副作用隔离：渲染阶段保持纯净，副作用集中到Commit阶段
    • 函数式优先：Hooks推动函数式编程，简化组件逻辑

附：生命周期完整对比图（新旧版本）
React生命周期对比图（来源：React官方社区图表）

Frontend►React

002-虚拟DOM

虚拟DOM深度解析与性能对比

一、虚拟DOM核心理解

本质与工作原理

1
2
3
4
5
graph LR
A[状态变化] --> B(生成新虚拟DOM树)
B --> C(Diff算法对比)
C --> D[计算最小变更集]
D --> E[批量更新真实DOM]

  1. 轻量级JS对象：

    • 本质：用JS对象模拟真实DOM结构
    • 数据结构示例：
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      {
        type: 'div',
        props: { 
          className: 'container',
          children: [
            { type: 'h1', props: { children: 'Title' } },
            { type: 'p', props: { children: 'Content' } }
          ]
        }
      }

  2. 核心价值：

    • 抽象层：解耦渲染逻辑与平台API
    • 批处理更新：合并多次状态变更（Event Loop机制）
    • 跨平台能力：同一套逻辑可渲染到DOM/Canvas/Native
    • 开发效率：声明式编程替代命令式DOM操作

  3. 工作流程：

    1. 状态变更触发重新渲染
    2. 生成新虚拟DOM树
    3. 与旧树进行Diff比较
    4. 计算出最小DOM操作序列
    5. 提交变更到真实DOM

二、全量更新 vs Diff更新性能对比

性能对比矩阵

场景 全量更新 Diff更新 胜出方
简单静态页面 极快（<1ms） 中等（diff计算） 全量更新
大型列表变更 极慢（>500ms） 快（局部更新） Diff
频繁小更新 卡顿（布局抖动） 平滑（批量处理） Diff
节点结构巨变 中等 中等（全树比较） 平手

关键场景详解：

  1. 简单页面更新（全量更新更快）

    1
    2
    3
    4
    5
    6
    // 全量更新实现
    document.body.innerHTML = `
      <div class="header">
        <h1>New Title</h1>
      </div>
    `;
    • 优势：直接字符串替换，无比较开销
    • 适用场景：静态营销页、登录弹窗等简单组件

  2. 大型列表更新（Diff完胜）

    1
    2
    3
    4
    5
    // 原始列表：1000个项目
    // 变更：仅修改第5项内容

    // 全量更新：重建1000个DOM节点（>300ms）
    // Diff更新：仅更新1个文本节点（<1ms）

  3. 高频交互场景（Diff完胜）

    1
    2
    3
    // 实时输入框 + 即时搜索建议
    // 全量更新：每次输入导致页面闪烁
    // Diff更新：只更新建议列表区域

三、Diff算法核心优化策略

  1. 分层比较（O(n)复杂度）

    1
    2
    3
    4
    5
    graph TD
    A[根节点] --> B[子节点1]
    A --> C[子节点2]
    B --> D[孙节点1]
    C --> E[孙节点2]
    • 规则：只同层比较，不跨层级移动
    • 优势：复杂度从O(n³)降到O(n)

  2. Key优化策略

    1
    2
    3
    4
    5
    // 无key：全部重新创建
    {items.map(item => <li>{item.text}</li>)}

    // 有key：复用DOM节点
    {items.map(item => <li key={item.id}>{item.text}</li>)}
    • 原理：通过key建立新旧节点映射关系
    • 性能提升：列表变更减少90%+ DOM操作

  3. 组件类型短路

    • 当组件类型变化时，直接销毁整棵子树
    • 避免不必要的深层比较

四、虚拟DOM的真实成本

  1. 内存开销：

    • 额外存储虚拟DOM树（通常<10%真实DOM内存）
    • 典型SPA应用：虚拟DOM占用约2-5MB内存

  2. 计算开销：

    • Diff计算时间 ≈ 0.1ms ~ 10ms（视节点数量）
    • 对比真实DOM操作成本：
      操作 耗时比例
      创建DOM节点 100x
      更新属性 10x
      Diff计算 1x

五、性能优化实践指南

  1. 避免过度渲染：

    1
    2
    3
    4
    // 使用React.memo优化
    const MemoComp = React.memo(({ data }) => (
      <ExpensiveComponent data={data} />
    ));

  2. 精准控制更新：

    1
    2
    3
    4
    // 使用shouldComponentUpdate
    shouldComponentUpdate(nextProps) {
      return nextProps.value !== this.props.value;
    }

  3. 关键更新策略：

    1
    2
    3
    4
    5
    6
    7
    8
    // 时间分片（React 18+）
    function App() {
      return (
        <Suspense>
          <TimeSlicedComponent />
        </Suspense>
      );
    }

六、现代框架演进趋势

  1. 编译时优化：

    • Svelte：编译时计算更新路径
    • SolidJS：细粒度响应式更新
    • 优势：消除运行时Diff开销

  2. 混合策略：

    1
    2
    3
    4
    graph LR
    A[状态变更] --> B{变更路径已知？}
    B -->|是| C[直接精准更新]
    B -->|否| D[虚拟DOM Diff]
    • Vue3：模板编译标记静态节点
    • Preact：Signals细粒度更新

总结结论

  1. 虚拟DOM核心价值：

    • 不是单纯的性能工具，而是开发体验与性能的平衡器
    • 为复杂应用提供可预测的更新策略

  2. 性能选择原则：

    1
    2
    3
    graph TD
    A[更新场景] -->|简单/静态| B[全量更新更快]
    A -->|复杂/动态| C[Diff更新更快]

  3. 现实应用建议：

    • SPA/复杂应用：坚持使用虚拟DOM方案
    • 微前端/微件：考虑混合策略（如Web Components）
    • 性能敏感模块：结合直接DOM操作（如canvas动画）

最终结论：虚拟DOM在绝大多数现代Web应用场景中，通过Diff更新策略实现了最优的综合性能表现，尤其在维护大型应用和团队协作时展现出不可替代的价值。