React生命周期钩子必用场景及两种定时器实现方案优劣对比

一、必须使用React生命周期钩子的场景 #

以下场景无法通过普通的render逻辑实现，必须依赖生命周期钩子：

• 组件挂载/卸载阶段的副作用操作：比如全局事件绑定/解绑、定时器初始化/销毁、首次数据请求、第三方类库的实例化/销毁，这类操作只需要在组件挂载/卸载时执行一次，不能放在会反复执行的render函数中。
• 状态/属性变更后的定向处理：比如props变化后需要同步更新内部state、仅特定属性变化时才重新发起数据请求，这类需要监听状态/属性变更的场景，需要用到componentDidUpdate等生命周期。
• 渲染性能优化：通过shouldComponentUpdate、React.PureComponent等能力判断是否需要跳过不必要的重渲染，这类控制渲染流程的逻辑无法在render中实现。
• 错误兜底处理：通过componentDidCatch捕获子组件渲染、生命周期执行过程中抛出的错误，做降级展示，这类错误捕获逻辑只能通过对应的生命周期实现。

二、修改方案的问题及生命周期方案的优势 #

你提供的修改方案虽然表面上可以实现时钟效果，但存在多个致命问题，生命周期方案的优势远不止精简代码和降低内存消耗，具体对比如下：

你的修改方案存在的核心问题 #

1. 违背React设计原则：render函数要求是纯函数，仅根据state和props返回UI结构，不允许包含修改状态、注册定时器这类副作用操作。React触发render的场景非常多（父组件重渲染、组件其他状态变更等），每次render都会创建新的定时器，你仅覆盖了最新的timerID，旧的定时器没有被清理，会出现定时器堆积、时间不准的问题。
2. 无法彻底清理资源：如果组件被卸载，你创建的所有定时器仍然会继续执行，调用setState时会触发React的内存泄漏警告，就算你在componentWillUnmount中清理timerID，也只能清掉最后一次render生成的定时器，之前多次render生成的无ID定时器无法清理，泄漏问题无法解决。
3. 执行时机不稳定：React的render阶段可能会因为高优先级任务调度被中断、重启，render中注册的定时器可能会被重复触发，计时逻辑完全不可控。

生命周期方案的核心优势 #

官方示例使用componentDidMount注册定时器的方案，解决了上述所有问题：

• 执行时机可控：componentDidMount仅在组件首次挂载到DOM后执行1次，只会注册1个定时器，不会出现重复注册的问题。
• 可彻底清理资源：你可以在componentWillUnmount中直接清理唯一的定时器ID，完全避免内存泄漏：

componentWillUnmount() {
  clearInterval(this.timerID)
}

• 逻辑分离易维护：渲染逻辑和副作用逻辑完全分离，后续修改定时器逻辑只需要调整生命周期内的代码，不会和渲染逻辑耦合，出现问题也更容易排查。
• 性能更稳定：不会生成大量无用定时器，也不会触发多余的重渲染，性能远优于你的修改方案。

补充：你贴的官方示例代码存在语法问题，setInterval的第一个参数需要是回调函数，正确写法应该是：

componentDidMount() {
  this.timerID = setInterval(() => {
    this.setState({
      date: new Date()
    })
  }, 1000)
}

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