拿“React 组件执行 - 生命周期”这个标题来说它其实涵盖了两个层面的东西一个是组件从创建到销毁的“生命周期”回调另一个是React内部对组件的“执行”时机控制。很多前端开发者背熟了componentDidMount、componentDidUpdate这几个钩子但一遇到父子组件嵌套、并发渲染、SSR 这类场景就蒙圈原因就是对“执行时机”的理解还停留在表面。这篇文章我打算从 React 16.x 到 18.x 的实际行为出发把生命周期和执行流程揉在一起讲清楚最后再拆几个高频面试题和实战坑点希望能帮你彻底打通这条链路。1. 先搞清楚React 组件执行过程到底分几个阶段1.1 组件执行的两条主线渲染阶段与提交阶段React 组件执行整个过程可以拆成两条大主线渲染阶段和提交阶段。这两条线很多人都搞混尤其是从 Vue 转过来的同学总觉得生命周期是一个接一个线性触发的但实际上 React 的处理方式是分两趟完成的。渲染阶段Render Phase负责调用你的组件函数计算出新的虚拟 DOM 结构。这个阶段React可以随时打断、重新开始甚至并发执行多个组件的渲染。关键点是这个阶段不能有副作用不能改DOM不能发请求因为你不能保证这个渲染结果最终会被提交。提交阶段Commit Phase才是真正把虚拟 DOM 的变化应用到真实 DOM 上的过程。到了这里才触发生命周期钩子比如componentDidMount、componentDidUpdate、componentWillUnmount等等。提交阶段是一气呵成的、同步不可中断的。我在面试里常问一个问题render阶段和commit阶段哪个阶段可以调用setState答案肯定是在commit阶段允许通过生命周期去更新状态但也要谨慎避免死循环。而在render阶段内部调用setState是绝对禁止的会直接报错提示“不能在渲染函数中更新状态”。1.2 在不同版本里生命周期名字和语义都变过React 组件的生命周期并不是一成不变的。如果你用过 React 15 和老的类组件肯定知道componentWillMount、componentWillReceiveProps、componentWillUpdate三个老钩子。React 16.3 引入了新的静态方法getDerivedStateFromProps和getSnapshotBeforeUpdate同时在 17.0 版本中正式移除这三个 Will 钩子16.3 之后已经加了 UNSAFE_ 前缀。目前官方推荐的做法是类组件只使用下面这几个钩子挂载时constructor-getDerivedStateFromProps-render-componentDidMount更新时getDerivedStateFromProps-shouldComponentUpdate-render-getSnapshotBeforeUpdate-componentDidUpdate卸载时componentWillUnmount这里有一个非常关键的点getDerivedStateFromProps是静态方法它拿不到this也无法在里面调用实例方法。它的作用只有一个——根据新的 props 计算出一个新的 state。很多人把它当成 Vue 的watch来用那就大错特错了。在绝大多数情况下getDerivedStateFromProps都是多余的直接使用派生状态反而会让代码更复杂。React 官方文档有一个专门的误区清单叫“你可能不需要使用派生状态”。2. 挂载阶段从类组件构造函数到 DOM 真正出现2.1 constructor 里能做什么、不能做什么类组件在挂载阶段第一个执行的就是constructor。很多人在这里犯的第一个错误是把props存进this.state或者把 props 赋值给一个内部字段来“备份”然后发现父组件后续更新 props 时这里的数据并不会自动同步于是莫名出现 bug。constructor的两个核心用途是初始化本地 state、绑定实例方法。注意从 React 16 开始类组件可以写字段声明比如state { count: 0 }这样连constructor都可以省略。当你在constructor里使用this.props时必须调用super(props)否则后面拿不到 props。这个细节很容易被忽略。我自己在实际开发中的习惯是尽量用函数组件加 Hooks但老项目里保留类组件时constructor里我只会写初始 state进行事件函数的 bind 操作而且如果只是给函数箭头绑定直接在类字段定义上写箭头函数即可连 bind 都能省。2.2 render 阶段的计算逻辑与纯函数约束执行完constructor或者getDerivedStateFromProps之后React 就会调用组件的render方法。render是最核心、最纯粹的函数它必须不产生任何副作用。你可以在里面读取this.state和this.props返回 JSX 结构或者 null。绝对不能在render里调用setState、修改 DOM、生成随机数并存入状态等操作否则渲染结果不稳定React 的协调过程就会混乱。我还经常提醒团队尽量不要在render里做复杂计算尤其是把一个大数组每次都filter、sort一遍。虽然不能说这是错的但在父组件频繁更新时会造成无谓的重复计算影响性能。这种场景应该用useMemo或者把计算结果提前准备好。render阶段本身就是高频执行的能减的负担就减掉。2.3 componentDidMount 的执行时机与 SSR 的差异componentDidMount是挂载阶段唯一一个允许副作用的钩子而且是在真实 DOM 插入之后才执行的。在这个钩子里可以操作 DOM、发请求、设置定时器。这里我要重点说一个很多人踩过的坑SSR 环境下componentDidMount不会执行。如果你用 Next.js 这类框架做服务端渲染类组件在服务端只执行constructor-getDerivedStateFromProps-render然后直接把 HTML 字符串返回给客户端。客户端做水合hydrate时才会补上事件和生命周期。所以在componentDidMount里写window.xxx是安全的但你千万别指望这段逻辑在服务端跑。如果你确实要区分当前环境需要判断typeof window ! undefined或者用框架提供的动态导入、useEffect专属副作用机制。我还遇到过一种问题组件里在componentDidMount中发请求但这个请求的数据其实并不需要从客户端发而是应该在服务端就预取好。这就引出了SSR 数据预获取方案——在 Next.js 的经典做法是在getServerSideProps或getStaticProps里取数据通过这些方案把数据作为 props 传给组件组件挂载后直接渲染根本不用等 useEffect 再去请求。所以 React 的生命周期意识在 SSR 场景下要重新调整服务端没有挂载完成这个时机所有数据预取都要前置到渲染入口。2.4 挂载顺序父组件与子组件的执行嵌套挂载阶段还有一个特别容易考倒人的点父子组件的执行顺序。假设父组件里渲染了一个子组件实际执行顺序是父组件constructor父组件getDerivedStateFromProps父组件render执行过程中遇到子组件子组件constructor子组件getDerivedStateFromProps子组件render子组件componentDidMount父组件componentDidMount注意所有子组件的componentDidMount会先于父组件的componentDidMount执行而子组件的render是在父组件的render过程中被调用的。React 需要先把整棵组件树的 DOM 全建出来再统一从叶子到根逐层触发componentDidMount。这个顺序如果你理解不了后面看更新阶段的顺序会非常难受。3. 更新阶段状态改变带来的完整执行链路3.1 触发更新的几种来源和getDerivedStateFromProps的定位组件更新无非三种来源父组件重新渲染导致自身 props 变化、组件内部调用setState、调用forceUpdate。三种触发路径最终都会走更新流程但细节有差别setState更新时shouldComponentUpdate会照常执行forceUpdate会跳过shouldComponentUpdate校验强制重新渲染props 更新时组件本身可能没有重新调用setState但仍然会走到getDerivedStateFromProps。getDerivedStateFromProps是每次渲染前都会执行不管更新来源是 props 还是 state。它必须是纯函数返回对象就代表新的 state返回 null 代表 state 不变。但这里有一个反直觉的地方当组件内部setState导致更新时getDerivedStateFromProps也会执行并且它的返回值会覆盖掉这次setState的部分结果。也就是说如果你在setState里改了一个字段而getDerivedStateFromProps的返回值里恰好包含这个字段那返回值会胜出。我见过一个很典型的反面案例某个组件用getDerivedStateFromProps来判断“props.id 变化时重置 state”结果用户在页面上通过setState修改了表单内容一旦点击翻页触发了 props 变化整个表单被强制重置用户填写的内容全丢了。这里更好的做法是把 id 变化当成重置信号放到componentDidUpdate里判断处理或者干脆使用“受控组件 key 强制重建”的方式。记住能不用getDerivedStateFromProps就不用。3.2 更新阶段父子组件的执行顺序与示例父组件重新渲染时更新阶段的执行顺序很有规律父组件getDerivedStateFromProps父组件shouldComponentUpdate父组件render子组件getDerivedStateFromProps子组件shouldComponentUpdate子组件render子组件getSnapshotBeforeUpdate父组件getSnapshotBeforeUpdate子组件componentDidUpdate父组件componentDidUpdate注意细节子组件的render先执行完然后 React 统一处理 DOM 变更再依次调用getSnapshotBeforeUpdate和componentDidUpdate。而且 DOM 更新顺序是子组件先提交父组件后提交但生命周期钩子同样遵循子先父后的顺序。这里有个高频面试题如果在父组件的render里通过条件逻辑切换子组件的类型同一个位置从ChildA /换成ChildB /React 会认为它们是“不同类型的组件”直接把 ChildA 卸载、ChildB 挂载而不是复用 DOM 结构。如果这两个组件结构相似React 也会销毁重建因为组件类型变了协调算法直接走重建分支。这一点在动态组件加载、Tab 切换场景里经常遇到容易造成状态丢失需要额外关注。3.3 shouldComponentUpdate 与 React.memo 的性能控制类组件里可以用shouldComponentUpdate判断是否跳过本次渲染。如果返回 false后面的render和componentDidUpdate都不会执行。注意返回 false 时getDerivedStateFromProps依然会执行因为新的 props 仍然需要被处理。这两个行为经常被混淆面试官也很爱考shouldComponentUpdate返回 false 会阻止getDerivedStateFromProps吗答案是不会。函数组件没有shouldComponentUpdate钩子但可以使用React.memo对 props 做浅比较达到类似效果。这里有个执行顺序问题React.memo包裹的组件在父组件重新渲染时会先比较 props 是否变化如果没有变化则直接跳过整个组件渲染。这个比较发生在父组件的render阶段相当于在调用组件函数之前就把组件短路了。写shouldComponentUpdate做深比较时需要特别小心。虽然手写深比较可以做到非常精细的跳过控制但深比较本身会消耗性能而且容易出现遗漏字段的问题导致组件长时间显示旧数据。我在实践中更推荐两种方案一是保持 props 和 state 结构扁平尽量让浅比较就能生效二是配合不可变数据每次更新产生新的引用这样React.memo的浅比较就能稳定命中跳过条件。3.4 获取更新前的 DOMgetSnapshotBeforeUpdate 的真实用途getSnapshotBeforeUpdate这个钩子可能很多人没用过但它在某些强交互场景下非常有用。它会在真实 DOM 更新之前被调用让你拿到更新前的 DOM 快照。返回值会作为第三个参数传给componentDidUpdate。典型场景是聊天列表新消息到达时如果用户正停留在列表顶部附近的旧位置我们希望保持滚动位置不变不要让列表自动滚到底部。处理方法是在getSnapshotBeforeUpdate里记录旧列表的滚动高度和内容高度计算出用户浏览的位置偏移量然后在componentDidUpdate里根据最新的列表总高度和刚才记录的快照差值手动设置新的scrollTop保证当前看到的区域相对稳定。这个钩子在 React 16.3 加入就是为了替代老componentWillUpdate在提交前读取 DOM 的需求。因为它能拿到提交前的真实 DOM 值所以比render阶段做判断可靠得多。我用过多次后最大的体会是能用快照解决的状态逻辑尽量不要写进 state 里因为快照是一次性的、瞬时的不参与渲染计算可以避免很多额外渲染。4. 卸载阶段与常见生命周期坑点4.1 componentWillUnmount 必须要做的清理工作卸载阶段只有一个生命周期componentWillUnmount。这个钩子适合做所有清理工作包括清除定时器、取消网络请求、移除全局事件监听、断开 WebSocket 连接、调用第三方实例的销毁方法等等。为什么必须做清理因为 React 组件卸载之后其实例和 DOM 都不存在了但如果定时器还活着回调里又调用了this.setStateReact 虽然不会直接崩溃但会出现“在卸载组件上调用 setState 的警告”并且造成内存泄漏、事件重复绑定等隐患。尤其是使用 SSE 或者 WebSocket 做实时更新的组件如果你在componentDidMount里建立了连接没有在componentWillUnmount里关闭页面路由切走再切回来时连接会越积越多后端很快就会被打爆。我做过一个文件监听面板用EventSource订阅文件变化当时就是因为在卸载时忘了close()切换几次路由后浏览器控制台全是连接错误排查了很久才发现是生命周期清理没做干净。函数组件里对应的是useEffect的返回值函数。多个 effect 的清理过程遵循“先清理后执行”和“逆序清理”的原则React 会在组件卸载时按 effect 注册顺序的反方向逐个调用清理函数。比如先注册 A effect再注册 B effect卸载时先执行 B 的清理再执行 A 的清理。依赖项变化触发重跑时也是先执行上一个 effect 的清理再执行新的 effect 主体。4.2 常见坑点异步回调更新、事件池、重复注册类组件时代有几个经典坑现在依然可能遇到第一个是异步回调里调用setState。组件卸载后异步请求才返回回调里还在调setState就会触发警告。常规解决办法是在卸载时用标志位标记组件是否已卸载回调里检查标志位再设置状态。现在函数组件用 Hooks 后React 官方已经移除了这个警告但内存泄漏问题依然可能存在所以信号量清理还是要做。第二个是合成事件池。React 16 及之前版本里合成事件对象是会被池化复用的事件回调异步读取event时其属性可能已经被置空。比如你在onClick里直接setTimeout(() console.log(event.target), 100)取到的可能是 null。React 17 移除了事件池机制已经不存在这个问题但如果你的项目还在维护老版本必须注意event.persist()的用法。第三个是重复注册事件监听。如果componentDidMount里注册了window.addEventListener(resize, this.handleResize)但在componentWillUnmount里没有移除组件挂载多次后会导致同一个处理函数被注册多次触发时执行多遍。这在 Tab 页缓存、动态弹窗等场景里特别容易出现。我见过一个项目管理页面打开关闭弹窗几十次后滚动事件响应越来越迟钝最后发现监听器重复注册了几十个。4.3 卸载顺序父组件和子组件谁先卸载更新阶段是子先父后卸载阶段则是父先子后。也就是说父组件开始卸载会先执行自己的componentWillUnmount然后再依次卸载子组件。这一点非常反直觉很多人以为是自底向上。实际顺序是父组件componentWillUnmount子组件componentWillUnmount子组件真实 DOM 移除父组件真实 DOM 移除这个顺序在操作共享资源时特别重要。比如父组件管理了一个全局的第三方实例子组件依赖这个实例做一些清理工作如果父组件的清理把实例销毁了子组件的清理就会报错。所以在设计这类资源时一定要让子组件先清理依赖或者让父组件延迟释放资源把破坏性操作放到最外层最后做。5. 函数组件的“生命周期”与 Hooks 执行视角5.1 从一个函数到每一次渲染useEffect 的时序真相Hooks 出现之后官方宣传的是“函数组件没有生命周期但有副作用同步机制”。但实际使用里大家还是会下意识地寻找 “DidMount 对应什么”。用useEffect模拟componentDidMount只需要把依赖数组传成空数组[]模拟componentDidUpdate就传一个依赖数组模拟componentWillUnmount就在 effect 返回值里写清理逻辑。但这里有一个最容易被忽略的核心差异class 组件的生命周期是基于组件实例的只会触发一次而函数组件的 effect 在每次渲染后都可能重新执行。所以如果你在useEffect(() { fetchData() }, [])里发请求它确实只发一次。但如果依赖数组写了某个 state只要这个 state 变化effect 就会重新执行这相当于一个“每次渲染后的更新钩子”并不是真正的componentDidUpdate——componentDidUpdate只有“更新阶段”才触发而 useEffect 在第一次挂载后的渲染中也会执行。还有一点useEffect在浏览器绘制完成之后才异步执行。因此如果你需要同步操作 DOM 或者读取布局应该使用useLayoutEffect它在 DOM 变更后、浏览器绘制前同步执行。两者在触摸事件、滚动位置、动画帧这类场景下差异非常明显。我做过一个轮播图组件当时的做法是在useEffect里设置初始的 translate 值结果每次刷新页面都会看到一次闪烁从第一张图跳到第二张图的位置。后来改成useLayoutEffect在浏览器绘制前就把位移设置好闪烁问题立刻消失。5.2 常用 Hooks 对组件执行时机的介入方式函数组件里除了useEffect还有几个 Hooks 会直接干预执行过程useState提供状态读取和更新函数更新状态会调度一次组件重新执行。useReducer适合复杂状态流转和setState一样触发更新后会走新的渲染过程。useMemo在渲染过程中执行计算并把结果缓存。它是在渲染期间执行的所以里面不能有副作用。useCallback缓存函数引用避免父子组件联动时子组件因函数引用变化而频繁渲染。useRef可以在跨渲染周期保存一个可变值修改它不会触发重新渲染。它非常适合用来记录上一次的状态值模拟类组件的实例字段。在函数组件里我们经常用useRef保存“最新值”然后配合useEffect或者事件监听读取。比如一个实时数据面板需要在 WebSocket 消息回调里读取最新的筛选条件如果直接在回调里闭包读取只能拿到组件首次渲染时的旧值。解决办法就是用useRef同步保存一份最新筛选条件回调里通过ref.current读取。这种方式本质上是绕过了 React 的渲染周期直接访问可变容器非常实用。5.3 父子组件通信如何影响生命周期串联父传子的常规方式是通过 props 传递数据子组件内部通过新 props 触发更新流程。子传父则一般通过回调函数父组件把函数通过 props 传给子组件子组件在事件中调用。回调函数里如果触发了父组件的setState那就会形成一次父组件的重新渲染子组件也会连带更新。这个链路的执行顺序和更新阶段完全一致父先渲染、子再渲染、子先提交、父后提交。这里有个优化点如果父组件每次渲染都重新创建一个新函数传给子组件子组件用React.memo包裹也阻止不了子组件重新渲染因为函数引用变了。所以要用useCallback包一层保证依赖不变时函数引用稳定。反过来如果子组件频繁调用父组件传入的回调且回调里改动了大范围状态那整棵子树都会重跑一遍必须结合状态拆分和 React.memo 做隔离。组件通信本身不复杂复杂的是通信触发状态变化之后生命周期链路怎么避免无意义的重复执行。我做过一个表格组件表格行里有一个“启用/停用”开关每次切换都要通过父组件回调更新一整张列表的缓存数据。最初实现很简单父组件直接setState更新整个数组结果翻页、排序时明显卡顿。后面把所有行数据拆成独立子组件每行都用React.memo包裹父组件更新列表时只传稳定引用行的开关状态通过子组件内部管理性能瞬间就正常了。由此可见通信方式直接决定渲染影响的半径。6. 并发模式、React Native 与 SSR 场景下的生命周期再认识6.1 并发渲染下生命周期不再“可信”React 18 推出的并发特性让渲染可以被中断、恢复、甚至丢弃。这意味着渲染阶段会被重复执行但提交阶段仍然保证一致。由于渲染阶段不能有副作用所以对于类组件里老版本遗留的在render前读取 DOM、或者执行副作用的逻辑React 已经通过废弃UNSAFE_钩子来规避。函数组件的useEffect和useLayoutEffect都只在提交后执行所以不受并发渲染的中断影响。但是并发模式下有一个重要的变化componentWillUnmount和 effect 的清理可能不会立即执行而是会延迟到真正提交的时候。开发者在“卸载”时释放资源的直觉要放宽——在React 18的 StrictMode 下组件挂载时会额外执行一次“模拟的卸载和重挂载”用来暴露副作用未正确清理的问题。这条规则让很多习惯在useEffect里发请求并在清理里取消请求的开发者措手不及——开发环境请求会发两次。这是预期行为不是 bug。6.2 React Native 启动白屏与生命周期的影响React Native 里也有生命周期问题而“启动白屏”很多时候就跟生命周期挂钩。RN 应用启动时JS 线程和原生视图的挂载是异步协作的。如果首页组件的数据都放在componentDidMount里请求在请求返回之前页面展示的是空白或 loading视觉上就是白屏。优化手段是把首屏关键数据提前预取通过原生端注入给 JS或者把静态配置直接打包在 JS bundle 里减少对网络请求的依赖。同时在根组件里用InteractionManager把非关键交互延后处理保证首屏绘制优先。RN 的生命周期和 Web React 大体一致但有一个特殊性原生渲染和 JS 侧的生命周期存在时间差不能完全依赖componentDidMount一定代表用户已经看到了界面。真正合适的曝光上报时机往往要配合onLayout事件或者InteractionManager.runAfterInteractions。6.3 数据请求与生命周期的匹配从轮询到 SSE/WebSocket这里串一下热词里的 SSE 和 WebSocket。如果在前端做一个“文件变化监听”用 React 组件实现的话常见的方案是在挂载时建立 SSE 或 WebSocket 连接在卸载时断开收到消息后通过setState更新界面。SSE 适合服务端单向推送WebSocket 适合双向实时通信。如果只是轮询文件变化更轻量的做法是setInterval配合useEffect把定时器清理写在 effect 返回函数里。这个场景最能检验生命周期功底定时器和网络连接都必须在卸载时清理清理函数里不能再用已卸载的组件状态否则会有隐性问题。React 18 并发模式下还要注意如果一个组件被挂载了多次比如同一路由下切换参数每次挂载都会重新建立连接若卸载清理不严谨连接数就会不断增加。我在实践中的做法是在 effect 内部先声明一个let cancelled false标志位收到消息后如果cancelled为 true 就丢弃在清理函数里设置cancelled true并 close 连接能稳妥避免绝大多数竞态问题。7. 面试题与避坑自检清单7.1 高频面试题拆解整理了这几年经过验证的高频面试题每条下面附上我的答题思路为什么推荐用函数组件而不是类组件函数组件更贴合 React 的设计模型——每次渲染都是一次新的函数调用状态和副作用会随着渲染同步更新不会像类组件那样出现 this 指向和实例字段同步问题Hooks 还能把相关逻辑聚合在一起避免生命周期钩子把无关代码硬凑在一起的状况。类组件里不同生命周期钩子经常要维护同一份逻辑维护成本高。setState是同步还是异步本质上是调度更新React 18 中的自动批处理让它在事件处理函数、生命周期、effect 里都可能表现为异步批量更新。但如果在setTimeout或者原生事件回调里调用且没有批处理环境它可能同步执行。具体执行时机要结合 React 版本和执行上下文判断答题时先讲批处理机制再讲版本差异最后说清楚“同步与异步只是表现关键是何时触发下一次渲染”。为什么render不能有副作用因为渲染阶段可能被并发打断、重放副作用如果放在 render 里会重复执行或者执行到一半被丢弃导致 UI 状态混乱。副作用必须放在提交阶段触发的生命周期或 effect 中这样才能保证每次副作用都对应一次真实的 DOM 提交。getDerivedStateFromProps和componentDidUpdate有什么区别前者在渲染前执行适合根据 props 计算 state但是覆盖逻辑容易出问题后者在提交后执行适合处理更新后的 DOM 操作和根据前后 props 差异做副作用。如果要做“props 变化后发请求”应该用componentDidUpdate里手动比较 prevProps 和 this.props而不是在getDerivedStateFromProps里发请求因为那里禁止副作用。React.memo和useMemo有什么关系它们一个是组件级别的渲染缓存一个是值级别的计算缓存。React.memo浅比较 props 后决定是否跳过组件渲染useMemo缓存一个值避免重复计算。两者经常配合使用但作用层面不同。为什么useEffect可以模拟生命周期但不等同于生命周期useEffect是“渲染后同步副作用”的机制它会在每次渲染提交后按依赖数组决定是否执行生命周期是“组件实例在特定阶段回调”的机制只对应特定时机。函数组件没有实例概念每次渲染都是独立闭包所以语义上比“生命周期”更准确。7.2 避坑自检清单下面这份清单是我在代码评审时经常用的你也可以拿去当自检表检查所有异步回调里是否在组件卸载后还调用setState或更新 Hooks 状态。检查useEffect的清理函数是否完善定时器、EventSource、WebSocket、事件监听、第三方实例销毁。检查getDerivedStateFromProps是否被滥用是否能在componentDidUpdate或 key 控制里解决。检查类组件里是否残留UNSAFE_钩子React 18 下这些钩子只适合特殊兼容场景不应出现在新代码里。检查render函数中是否有随机数、Date.now()、直接修改外部对象等不稳定行为。检查列表组件是否缺少稳定keykey 变化会导致组件状态被意外重置或复用错乱。检查父子组件通信的回调函数是否稳定父组件重渲染是否导致子组件大规模重渲染。这份清单的价值不是“背下来”而是每一条背后都对应一个真实线上事故。我做代码评审时看生命周期的相关代码重点不是看钩子名字对不对而是看“副作用有没有安放在正确的时机”“清理工作有没有做干净”“渲染路径有没有被意外中断”。7.3 关于执行时机我最后想强调的一个思维转变很多人学了生命周期之后总喜欢在组件里硬找“挂载了”这个时机去初始化一切。但实际操作中组件挂载时机和用户可交互时机之间往往存在很大距离。要把关注点从“钩子名”切换到“副作用执行的时机”。举一个简单例子一个列表页面滚动到底部要加载下一页。如果加载请求放在componentDidMount里页面一进来就开始请求第一页。但如果列表组件本身并不需要及时请求而是等用户搜索条件变化后再请求那这个请求就不该放挂载时机而应该放在“条件变化”的事件回调里。把数据请求和“用户意图”绑定而不是和“组件存在”绑定是 React 组件执行设计里更高级、更实用的思路。同样轮播图组件的自动播放定时器、编辑器组件的内容初始化、图表组件的 resize 监听这些都不能只盯着挂载和卸载还要考虑窗口尺寸变化、数据源切换、配置项合并这些分支。每一次执行时机的选择都决定了组件行为是否正确。最后分享一个我自己的小习惯我给团队定的规矩是——组件初始化不做任何数据请求所有数据请求都放到事件驱动或者刷新机制中useEffect只做“数据到位后的副作用同步”不做“初始化动作”。这条规则虽然不能覆盖所有场景但至少把大量因生命周期误用导致的重复请求和闪屏问题消灭在了源头。包括在 React Native 中减少白屏核心思路也是一样的不要在首屏生命周期里做重活把重活留给更精准的执行时机。组件执行这件事说到底就是“算 UI”和“动 DOM”两趟流程再加上“什么时候该算、什么时候该动、什么时候该清理”的时机把控。你可以不背下所有钩子名字但必须理解每一次渲染、每一次提交背后发生的事。实际项目里遇到诡异 Bug十有八九都是时机问题而不是代码逻辑问题把生命周期这层想透了排查问题的速度会快很多。
React组件执行与生命周期：从渲染到提交的时机解析
拿“React 组件执行 - 生命周期”这个标题来说它其实涵盖了两个层面的东西一个是组件从创建到销毁的“生命周期”回调另一个是React内部对组件的“执行”时机控制。很多前端开发者背熟了componentDidMount、componentDidUpdate这几个钩子但一遇到父子组件嵌套、并发渲染、SSR 这类场景就蒙圈原因就是对“执行时机”的理解还停留在表面。这篇文章我打算从 React 16.x 到 18.x 的实际行为出发把生命周期和执行流程揉在一起讲清楚最后再拆几个高频面试题和实战坑点希望能帮你彻底打通这条链路。1. 先搞清楚React 组件执行过程到底分几个阶段1.1 组件执行的两条主线渲染阶段与提交阶段React 组件执行整个过程可以拆成两条大主线渲染阶段和提交阶段。这两条线很多人都搞混尤其是从 Vue 转过来的同学总觉得生命周期是一个接一个线性触发的但实际上 React 的处理方式是分两趟完成的。渲染阶段Render Phase负责调用你的组件函数计算出新的虚拟 DOM 结构。这个阶段React可以随时打断、重新开始甚至并发执行多个组件的渲染。关键点是这个阶段不能有副作用不能改DOM不能发请求因为你不能保证这个渲染结果最终会被提交。提交阶段Commit Phase才是真正把虚拟 DOM 的变化应用到真实 DOM 上的过程。到了这里才触发生命周期钩子比如componentDidMount、componentDidUpdate、componentWillUnmount等等。提交阶段是一气呵成的、同步不可中断的。我在面试里常问一个问题render阶段和commit阶段哪个阶段可以调用setState答案肯定是在commit阶段允许通过生命周期去更新状态但也要谨慎避免死循环。而在render阶段内部调用setState是绝对禁止的会直接报错提示“不能在渲染函数中更新状态”。1.2 在不同版本里生命周期名字和语义都变过React 组件的生命周期并不是一成不变的。如果你用过 React 15 和老的类组件肯定知道componentWillMount、componentWillReceiveProps、componentWillUpdate三个老钩子。React 16.3 引入了新的静态方法getDerivedStateFromProps和getSnapshotBeforeUpdate同时在 17.0 版本中正式移除这三个 Will 钩子16.3 之后已经加了 UNSAFE_ 前缀。目前官方推荐的做法是类组件只使用下面这几个钩子挂载时constructor-getDerivedStateFromProps-render-componentDidMount更新时getDerivedStateFromProps-shouldComponentUpdate-render-getSnapshotBeforeUpdate-componentDidUpdate卸载时componentWillUnmount这里有一个非常关键的点getDerivedStateFromProps是静态方法它拿不到this也无法在里面调用实例方法。它的作用只有一个——根据新的 props 计算出一个新的 state。很多人把它当成 Vue 的watch来用那就大错特错了。在绝大多数情况下getDerivedStateFromProps都是多余的直接使用派生状态反而会让代码更复杂。React 官方文档有一个专门的误区清单叫“你可能不需要使用派生状态”。2. 挂载阶段从类组件构造函数到 DOM 真正出现2.1 constructor 里能做什么、不能做什么类组件在挂载阶段第一个执行的就是constructor。很多人在这里犯的第一个错误是把props存进this.state或者把 props 赋值给一个内部字段来“备份”然后发现父组件后续更新 props 时这里的数据并不会自动同步于是莫名出现 bug。constructor的两个核心用途是初始化本地 state、绑定实例方法。注意从 React 16 开始类组件可以写字段声明比如state { count: 0 }这样连constructor都可以省略。当你在constructor里使用this.props时必须调用super(props)否则后面拿不到 props。这个细节很容易被忽略。我自己在实际开发中的习惯是尽量用函数组件加 Hooks但老项目里保留类组件时constructor里我只会写初始 state进行事件函数的 bind 操作而且如果只是给函数箭头绑定直接在类字段定义上写箭头函数即可连 bind 都能省。2.2 render 阶段的计算逻辑与纯函数约束执行完constructor或者getDerivedStateFromProps之后React 就会调用组件的render方法。render是最核心、最纯粹的函数它必须不产生任何副作用。你可以在里面读取this.state和this.props返回 JSX 结构或者 null。绝对不能在render里调用setState、修改 DOM、生成随机数并存入状态等操作否则渲染结果不稳定React 的协调过程就会混乱。我还经常提醒团队尽量不要在render里做复杂计算尤其是把一个大数组每次都filter、sort一遍。虽然不能说这是错的但在父组件频繁更新时会造成无谓的重复计算影响性能。这种场景应该用useMemo或者把计算结果提前准备好。render阶段本身就是高频执行的能减的负担就减掉。2.3 componentDidMount 的执行时机与 SSR 的差异componentDidMount是挂载阶段唯一一个允许副作用的钩子而且是在真实 DOM 插入之后才执行的。在这个钩子里可以操作 DOM、发请求、设置定时器。这里我要重点说一个很多人踩过的坑SSR 环境下componentDidMount不会执行。如果你用 Next.js 这类框架做服务端渲染类组件在服务端只执行constructor-getDerivedStateFromProps-render然后直接把 HTML 字符串返回给客户端。客户端做水合hydrate时才会补上事件和生命周期。所以在componentDidMount里写window.xxx是安全的但你千万别指望这段逻辑在服务端跑。如果你确实要区分当前环境需要判断typeof window ! undefined或者用框架提供的动态导入、useEffect专属副作用机制。我还遇到过一种问题组件里在componentDidMount中发请求但这个请求的数据其实并不需要从客户端发而是应该在服务端就预取好。这就引出了SSR 数据预获取方案——在 Next.js 的经典做法是在getServerSideProps或getStaticProps里取数据通过这些方案把数据作为 props 传给组件组件挂载后直接渲染根本不用等 useEffect 再去请求。所以 React 的生命周期意识在 SSR 场景下要重新调整服务端没有挂载完成这个时机所有数据预取都要前置到渲染入口。2.4 挂载顺序父组件与子组件的执行嵌套挂载阶段还有一个特别容易考倒人的点父子组件的执行顺序。假设父组件里渲染了一个子组件实际执行顺序是父组件constructor父组件getDerivedStateFromProps父组件render执行过程中遇到子组件子组件constructor子组件getDerivedStateFromProps子组件render子组件componentDidMount父组件componentDidMount注意所有子组件的componentDidMount会先于父组件的componentDidMount执行而子组件的render是在父组件的render过程中被调用的。React 需要先把整棵组件树的 DOM 全建出来再统一从叶子到根逐层触发componentDidMount。这个顺序如果你理解不了后面看更新阶段的顺序会非常难受。3. 更新阶段状态改变带来的完整执行链路3.1 触发更新的几种来源和getDerivedStateFromProps的定位组件更新无非三种来源父组件重新渲染导致自身 props 变化、组件内部调用setState、调用forceUpdate。三种触发路径最终都会走更新流程但细节有差别setState更新时shouldComponentUpdate会照常执行forceUpdate会跳过shouldComponentUpdate校验强制重新渲染props 更新时组件本身可能没有重新调用setState但仍然会走到getDerivedStateFromProps。getDerivedStateFromProps是每次渲染前都会执行不管更新来源是 props 还是 state。它必须是纯函数返回对象就代表新的 state返回 null 代表 state 不变。但这里有一个反直觉的地方当组件内部setState导致更新时getDerivedStateFromProps也会执行并且它的返回值会覆盖掉这次setState的部分结果。也就是说如果你在setState里改了一个字段而getDerivedStateFromProps的返回值里恰好包含这个字段那返回值会胜出。我见过一个很典型的反面案例某个组件用getDerivedStateFromProps来判断“props.id 变化时重置 state”结果用户在页面上通过setState修改了表单内容一旦点击翻页触发了 props 变化整个表单被强制重置用户填写的内容全丢了。这里更好的做法是把 id 变化当成重置信号放到componentDidUpdate里判断处理或者干脆使用“受控组件 key 强制重建”的方式。记住能不用getDerivedStateFromProps就不用。3.2 更新阶段父子组件的执行顺序与示例父组件重新渲染时更新阶段的执行顺序很有规律父组件getDerivedStateFromProps父组件shouldComponentUpdate父组件render子组件getDerivedStateFromProps子组件shouldComponentUpdate子组件render子组件getSnapshotBeforeUpdate父组件getSnapshotBeforeUpdate子组件componentDidUpdate父组件componentDidUpdate注意细节子组件的render先执行完然后 React 统一处理 DOM 变更再依次调用getSnapshotBeforeUpdate和componentDidUpdate。而且 DOM 更新顺序是子组件先提交父组件后提交但生命周期钩子同样遵循子先父后的顺序。这里有个高频面试题如果在父组件的render里通过条件逻辑切换子组件的类型同一个位置从ChildA /换成ChildB /React 会认为它们是“不同类型的组件”直接把 ChildA 卸载、ChildB 挂载而不是复用 DOM 结构。如果这两个组件结构相似React 也会销毁重建因为组件类型变了协调算法直接走重建分支。这一点在动态组件加载、Tab 切换场景里经常遇到容易造成状态丢失需要额外关注。3.3 shouldComponentUpdate 与 React.memo 的性能控制类组件里可以用shouldComponentUpdate判断是否跳过本次渲染。如果返回 false后面的render和componentDidUpdate都不会执行。注意返回 false 时getDerivedStateFromProps依然会执行因为新的 props 仍然需要被处理。这两个行为经常被混淆面试官也很爱考shouldComponentUpdate返回 false 会阻止getDerivedStateFromProps吗答案是不会。函数组件没有shouldComponentUpdate钩子但可以使用React.memo对 props 做浅比较达到类似效果。这里有个执行顺序问题React.memo包裹的组件在父组件重新渲染时会先比较 props 是否变化如果没有变化则直接跳过整个组件渲染。这个比较发生在父组件的render阶段相当于在调用组件函数之前就把组件短路了。写shouldComponentUpdate做深比较时需要特别小心。虽然手写深比较可以做到非常精细的跳过控制但深比较本身会消耗性能而且容易出现遗漏字段的问题导致组件长时间显示旧数据。我在实践中更推荐两种方案一是保持 props 和 state 结构扁平尽量让浅比较就能生效二是配合不可变数据每次更新产生新的引用这样React.memo的浅比较就能稳定命中跳过条件。3.4 获取更新前的 DOMgetSnapshotBeforeUpdate 的真实用途getSnapshotBeforeUpdate这个钩子可能很多人没用过但它在某些强交互场景下非常有用。它会在真实 DOM 更新之前被调用让你拿到更新前的 DOM 快照。返回值会作为第三个参数传给componentDidUpdate。典型场景是聊天列表新消息到达时如果用户正停留在列表顶部附近的旧位置我们希望保持滚动位置不变不要让列表自动滚到底部。处理方法是在getSnapshotBeforeUpdate里记录旧列表的滚动高度和内容高度计算出用户浏览的位置偏移量然后在componentDidUpdate里根据最新的列表总高度和刚才记录的快照差值手动设置新的scrollTop保证当前看到的区域相对稳定。这个钩子在 React 16.3 加入就是为了替代老componentWillUpdate在提交前读取 DOM 的需求。因为它能拿到提交前的真实 DOM 值所以比render阶段做判断可靠得多。我用过多次后最大的体会是能用快照解决的状态逻辑尽量不要写进 state 里因为快照是一次性的、瞬时的不参与渲染计算可以避免很多额外渲染。4. 卸载阶段与常见生命周期坑点4.1 componentWillUnmount 必须要做的清理工作卸载阶段只有一个生命周期componentWillUnmount。这个钩子适合做所有清理工作包括清除定时器、取消网络请求、移除全局事件监听、断开 WebSocket 连接、调用第三方实例的销毁方法等等。为什么必须做清理因为 React 组件卸载之后其实例和 DOM 都不存在了但如果定时器还活着回调里又调用了this.setStateReact 虽然不会直接崩溃但会出现“在卸载组件上调用 setState 的警告”并且造成内存泄漏、事件重复绑定等隐患。尤其是使用 SSE 或者 WebSocket 做实时更新的组件如果你在componentDidMount里建立了连接没有在componentWillUnmount里关闭页面路由切走再切回来时连接会越积越多后端很快就会被打爆。我做过一个文件监听面板用EventSource订阅文件变化当时就是因为在卸载时忘了close()切换几次路由后浏览器控制台全是连接错误排查了很久才发现是生命周期清理没做干净。函数组件里对应的是useEffect的返回值函数。多个 effect 的清理过程遵循“先清理后执行”和“逆序清理”的原则React 会在组件卸载时按 effect 注册顺序的反方向逐个调用清理函数。比如先注册 A effect再注册 B effect卸载时先执行 B 的清理再执行 A 的清理。依赖项变化触发重跑时也是先执行上一个 effect 的清理再执行新的 effect 主体。4.2 常见坑点异步回调更新、事件池、重复注册类组件时代有几个经典坑现在依然可能遇到第一个是异步回调里调用setState。组件卸载后异步请求才返回回调里还在调setState就会触发警告。常规解决办法是在卸载时用标志位标记组件是否已卸载回调里检查标志位再设置状态。现在函数组件用 Hooks 后React 官方已经移除了这个警告但内存泄漏问题依然可能存在所以信号量清理还是要做。第二个是合成事件池。React 16 及之前版本里合成事件对象是会被池化复用的事件回调异步读取event时其属性可能已经被置空。比如你在onClick里直接setTimeout(() console.log(event.target), 100)取到的可能是 null。React 17 移除了事件池机制已经不存在这个问题但如果你的项目还在维护老版本必须注意event.persist()的用法。第三个是重复注册事件监听。如果componentDidMount里注册了window.addEventListener(resize, this.handleResize)但在componentWillUnmount里没有移除组件挂载多次后会导致同一个处理函数被注册多次触发时执行多遍。这在 Tab 页缓存、动态弹窗等场景里特别容易出现。我见过一个项目管理页面打开关闭弹窗几十次后滚动事件响应越来越迟钝最后发现监听器重复注册了几十个。4.3 卸载顺序父组件和子组件谁先卸载更新阶段是子先父后卸载阶段则是父先子后。也就是说父组件开始卸载会先执行自己的componentWillUnmount然后再依次卸载子组件。这一点非常反直觉很多人以为是自底向上。实际顺序是父组件componentWillUnmount子组件componentWillUnmount子组件真实 DOM 移除父组件真实 DOM 移除这个顺序在操作共享资源时特别重要。比如父组件管理了一个全局的第三方实例子组件依赖这个实例做一些清理工作如果父组件的清理把实例销毁了子组件的清理就会报错。所以在设计这类资源时一定要让子组件先清理依赖或者让父组件延迟释放资源把破坏性操作放到最外层最后做。5. 函数组件的“生命周期”与 Hooks 执行视角5.1 从一个函数到每一次渲染useEffect 的时序真相Hooks 出现之后官方宣传的是“函数组件没有生命周期但有副作用同步机制”。但实际使用里大家还是会下意识地寻找 “DidMount 对应什么”。用useEffect模拟componentDidMount只需要把依赖数组传成空数组[]模拟componentDidUpdate就传一个依赖数组模拟componentWillUnmount就在 effect 返回值里写清理逻辑。但这里有一个最容易被忽略的核心差异class 组件的生命周期是基于组件实例的只会触发一次而函数组件的 effect 在每次渲染后都可能重新执行。所以如果你在useEffect(() { fetchData() }, [])里发请求它确实只发一次。但如果依赖数组写了某个 state只要这个 state 变化effect 就会重新执行这相当于一个“每次渲染后的更新钩子”并不是真正的componentDidUpdate——componentDidUpdate只有“更新阶段”才触发而 useEffect 在第一次挂载后的渲染中也会执行。还有一点useEffect在浏览器绘制完成之后才异步执行。因此如果你需要同步操作 DOM 或者读取布局应该使用useLayoutEffect它在 DOM 变更后、浏览器绘制前同步执行。两者在触摸事件、滚动位置、动画帧这类场景下差异非常明显。我做过一个轮播图组件当时的做法是在useEffect里设置初始的 translate 值结果每次刷新页面都会看到一次闪烁从第一张图跳到第二张图的位置。后来改成useLayoutEffect在浏览器绘制前就把位移设置好闪烁问题立刻消失。5.2 常用 Hooks 对组件执行时机的介入方式函数组件里除了useEffect还有几个 Hooks 会直接干预执行过程useState提供状态读取和更新函数更新状态会调度一次组件重新执行。useReducer适合复杂状态流转和setState一样触发更新后会走新的渲染过程。useMemo在渲染过程中执行计算并把结果缓存。它是在渲染期间执行的所以里面不能有副作用。useCallback缓存函数引用避免父子组件联动时子组件因函数引用变化而频繁渲染。useRef可以在跨渲染周期保存一个可变值修改它不会触发重新渲染。它非常适合用来记录上一次的状态值模拟类组件的实例字段。在函数组件里我们经常用useRef保存“最新值”然后配合useEffect或者事件监听读取。比如一个实时数据面板需要在 WebSocket 消息回调里读取最新的筛选条件如果直接在回调里闭包读取只能拿到组件首次渲染时的旧值。解决办法就是用useRef同步保存一份最新筛选条件回调里通过ref.current读取。这种方式本质上是绕过了 React 的渲染周期直接访问可变容器非常实用。5.3 父子组件通信如何影响生命周期串联父传子的常规方式是通过 props 传递数据子组件内部通过新 props 触发更新流程。子传父则一般通过回调函数父组件把函数通过 props 传给子组件子组件在事件中调用。回调函数里如果触发了父组件的setState那就会形成一次父组件的重新渲染子组件也会连带更新。这个链路的执行顺序和更新阶段完全一致父先渲染、子再渲染、子先提交、父后提交。这里有个优化点如果父组件每次渲染都重新创建一个新函数传给子组件子组件用React.memo包裹也阻止不了子组件重新渲染因为函数引用变了。所以要用useCallback包一层保证依赖不变时函数引用稳定。反过来如果子组件频繁调用父组件传入的回调且回调里改动了大范围状态那整棵子树都会重跑一遍必须结合状态拆分和 React.memo 做隔离。组件通信本身不复杂复杂的是通信触发状态变化之后生命周期链路怎么避免无意义的重复执行。我做过一个表格组件表格行里有一个“启用/停用”开关每次切换都要通过父组件回调更新一整张列表的缓存数据。最初实现很简单父组件直接setState更新整个数组结果翻页、排序时明显卡顿。后面把所有行数据拆成独立子组件每行都用React.memo包裹父组件更新列表时只传稳定引用行的开关状态通过子组件内部管理性能瞬间就正常了。由此可见通信方式直接决定渲染影响的半径。6. 并发模式、React Native 与 SSR 场景下的生命周期再认识6.1 并发渲染下生命周期不再“可信”React 18 推出的并发特性让渲染可以被中断、恢复、甚至丢弃。这意味着渲染阶段会被重复执行但提交阶段仍然保证一致。由于渲染阶段不能有副作用所以对于类组件里老版本遗留的在render前读取 DOM、或者执行副作用的逻辑React 已经通过废弃UNSAFE_钩子来规避。函数组件的useEffect和useLayoutEffect都只在提交后执行所以不受并发渲染的中断影响。但是并发模式下有一个重要的变化componentWillUnmount和 effect 的清理可能不会立即执行而是会延迟到真正提交的时候。开发者在“卸载”时释放资源的直觉要放宽——在React 18的 StrictMode 下组件挂载时会额外执行一次“模拟的卸载和重挂载”用来暴露副作用未正确清理的问题。这条规则让很多习惯在useEffect里发请求并在清理里取消请求的开发者措手不及——开发环境请求会发两次。这是预期行为不是 bug。6.2 React Native 启动白屏与生命周期的影响React Native 里也有生命周期问题而“启动白屏”很多时候就跟生命周期挂钩。RN 应用启动时JS 线程和原生视图的挂载是异步协作的。如果首页组件的数据都放在componentDidMount里请求在请求返回之前页面展示的是空白或 loading视觉上就是白屏。优化手段是把首屏关键数据提前预取通过原生端注入给 JS或者把静态配置直接打包在 JS bundle 里减少对网络请求的依赖。同时在根组件里用InteractionManager把非关键交互延后处理保证首屏绘制优先。RN 的生命周期和 Web React 大体一致但有一个特殊性原生渲染和 JS 侧的生命周期存在时间差不能完全依赖componentDidMount一定代表用户已经看到了界面。真正合适的曝光上报时机往往要配合onLayout事件或者InteractionManager.runAfterInteractions。6.3 数据请求与生命周期的匹配从轮询到 SSE/WebSocket这里串一下热词里的 SSE 和 WebSocket。如果在前端做一个“文件变化监听”用 React 组件实现的话常见的方案是在挂载时建立 SSE 或 WebSocket 连接在卸载时断开收到消息后通过setState更新界面。SSE 适合服务端单向推送WebSocket 适合双向实时通信。如果只是轮询文件变化更轻量的做法是setInterval配合useEffect把定时器清理写在 effect 返回函数里。这个场景最能检验生命周期功底定时器和网络连接都必须在卸载时清理清理函数里不能再用已卸载的组件状态否则会有隐性问题。React 18 并发模式下还要注意如果一个组件被挂载了多次比如同一路由下切换参数每次挂载都会重新建立连接若卸载清理不严谨连接数就会不断增加。我在实践中的做法是在 effect 内部先声明一个let cancelled false标志位收到消息后如果cancelled为 true 就丢弃在清理函数里设置cancelled true并 close 连接能稳妥避免绝大多数竞态问题。7. 面试题与避坑自检清单7.1 高频面试题拆解整理了这几年经过验证的高频面试题每条下面附上我的答题思路为什么推荐用函数组件而不是类组件函数组件更贴合 React 的设计模型——每次渲染都是一次新的函数调用状态和副作用会随着渲染同步更新不会像类组件那样出现 this 指向和实例字段同步问题Hooks 还能把相关逻辑聚合在一起避免生命周期钩子把无关代码硬凑在一起的状况。类组件里不同生命周期钩子经常要维护同一份逻辑维护成本高。setState是同步还是异步本质上是调度更新React 18 中的自动批处理让它在事件处理函数、生命周期、effect 里都可能表现为异步批量更新。但如果在setTimeout或者原生事件回调里调用且没有批处理环境它可能同步执行。具体执行时机要结合 React 版本和执行上下文判断答题时先讲批处理机制再讲版本差异最后说清楚“同步与异步只是表现关键是何时触发下一次渲染”。为什么render不能有副作用因为渲染阶段可能被并发打断、重放副作用如果放在 render 里会重复执行或者执行到一半被丢弃导致 UI 状态混乱。副作用必须放在提交阶段触发的生命周期或 effect 中这样才能保证每次副作用都对应一次真实的 DOM 提交。getDerivedStateFromProps和componentDidUpdate有什么区别前者在渲染前执行适合根据 props 计算 state但是覆盖逻辑容易出问题后者在提交后执行适合处理更新后的 DOM 操作和根据前后 props 差异做副作用。如果要做“props 变化后发请求”应该用componentDidUpdate里手动比较 prevProps 和 this.props而不是在getDerivedStateFromProps里发请求因为那里禁止副作用。React.memo和useMemo有什么关系它们一个是组件级别的渲染缓存一个是值级别的计算缓存。React.memo浅比较 props 后决定是否跳过组件渲染useMemo缓存一个值避免重复计算。两者经常配合使用但作用层面不同。为什么useEffect可以模拟生命周期但不等同于生命周期useEffect是“渲染后同步副作用”的机制它会在每次渲染提交后按依赖数组决定是否执行生命周期是“组件实例在特定阶段回调”的机制只对应特定时机。函数组件没有实例概念每次渲染都是独立闭包所以语义上比“生命周期”更准确。7.2 避坑自检清单下面这份清单是我在代码评审时经常用的你也可以拿去当自检表检查所有异步回调里是否在组件卸载后还调用setState或更新 Hooks 状态。检查useEffect的清理函数是否完善定时器、EventSource、WebSocket、事件监听、第三方实例销毁。检查getDerivedStateFromProps是否被滥用是否能在componentDidUpdate或 key 控制里解决。检查类组件里是否残留UNSAFE_钩子React 18 下这些钩子只适合特殊兼容场景不应出现在新代码里。检查render函数中是否有随机数、Date.now()、直接修改外部对象等不稳定行为。检查列表组件是否缺少稳定keykey 变化会导致组件状态被意外重置或复用错乱。检查父子组件通信的回调函数是否稳定父组件重渲染是否导致子组件大规模重渲染。这份清单的价值不是“背下来”而是每一条背后都对应一个真实线上事故。我做代码评审时看生命周期的相关代码重点不是看钩子名字对不对而是看“副作用有没有安放在正确的时机”“清理工作有没有做干净”“渲染路径有没有被意外中断”。7.3 关于执行时机我最后想强调的一个思维转变很多人学了生命周期之后总喜欢在组件里硬找“挂载了”这个时机去初始化一切。但实际操作中组件挂载时机和用户可交互时机之间往往存在很大距离。要把关注点从“钩子名”切换到“副作用执行的时机”。举一个简单例子一个列表页面滚动到底部要加载下一页。如果加载请求放在componentDidMount里页面一进来就开始请求第一页。但如果列表组件本身并不需要及时请求而是等用户搜索条件变化后再请求那这个请求就不该放挂载时机而应该放在“条件变化”的事件回调里。把数据请求和“用户意图”绑定而不是和“组件存在”绑定是 React 组件执行设计里更高级、更实用的思路。同样轮播图组件的自动播放定时器、编辑器组件的内容初始化、图表组件的 resize 监听这些都不能只盯着挂载和卸载还要考虑窗口尺寸变化、数据源切换、配置项合并这些分支。每一次执行时机的选择都决定了组件行为是否正确。最后分享一个我自己的小习惯我给团队定的规矩是——组件初始化不做任何数据请求所有数据请求都放到事件驱动或者刷新机制中useEffect只做“数据到位后的副作用同步”不做“初始化动作”。这条规则虽然不能覆盖所有场景但至少把大量因生命周期误用导致的重复请求和闪屏问题消灭在了源头。包括在 React Native 中减少白屏核心思路也是一样的不要在首屏生命周期里做重活把重活留给更精准的执行时机。组件执行这件事说到底就是“算 UI”和“动 DOM”两趟流程再加上“什么时候该算、什么时候该动、什么时候该清理”的时机把控。你可以不背下所有钩子名字但必须理解每一次渲染、每一次提交背后发生的事。实际项目里遇到诡异 Bug十有八九都是时机问题而不是代码逻辑问题把生命周期这层想透了排查问题的速度会快很多。
