JSX中onClick内联箭头函数为何被建议改为预定义处理函数

首先先纠正一个常见误区：你同事给出的调整写法，根本没有解决他所说的「内联函数性能问题」。

先看你最开始的内联写法：

const MyComp = () => <button onClick={() => navigate('/')}>home</button>

再看你同事建议的提取写法：

const MyComp = () => {
   const handleClick = () => navigate('/')
   return <button onClick={handleClick}>home</button>
}

这两种写法在运行时的表现几乎没有区别：

• 每次MyComp组件重渲染、执行组件函数体的时候，两种写法都会创建一个全新的箭头函数实例。后者只是把新创建的函数赋值给了handleClick这个中间变量，再传给onClick，并没有减少函数创建的开销，传给button的函数引用每次渲染也都是新的，不存在「更省性能」的说法。
• 真正能让函数引用在多次渲染间保持稳定的写法，是给提取的函数包上useCallback：

  const MyComp = () => {
     const handleClick = useCallback(() => navigate('/'), [])
     return <button onClick={handleClick}>home</button>
  }
  

  只有这种写法，才能在组件重渲染时复用同一个函数引用，也是网上传言「内联函数有性能问题」的唯一参照场景。

这个说法是React早期class组件时代遗留的认知，存在非常严格的适用前提，被很多人不加分辨地放大成了通用规范：

• 性能损耗的唯一来源：如果接收函数prop的子组件做了重渲染优化（比如类组件继承PureComponent、函数组件包裹了React.memo），那么每次渲染传新的函数引用，会让浅比较逻辑判定prop发生变化，触发子组件不必要的重渲染。
• 这个损耗的实际影响极小：现代JS引擎创建一个简单箭头函数的开销是纳秒级的，就算是长列表里几百个带内联函数的项，这点开销也根本不会造成用户可感知的卡顿，只有在子组件本身重渲染成本极高（比如承载了复杂图表、大尺寸表格、上千个表单项）的时候，多余的重渲染才会带来实际的性能问题。
• 日常业务开发中90%以上的场景，内联函数都不会造成任何性能问题，React官方文档也从未禁止内联函数的写法。

提取函数从来都不是为了虚无缥缈的性能，核心目的是提升代码可维护性：

• 当事件处理逻辑超过3行、包含复杂判断或者多步操作时，内联写在JSX属性里会让模板结构变得臃肿难读，提取成具名的handleXxx函数，既能让JSX结构更清晰，也能把事件逻辑收敛到单独位置方便后续修改。
• 当同一个事件处理逻辑需要被多个元素、多个组件复用时，提取出来可以避免重复写相同代码。
• 当你确实需要把函数传给包裹了React.memo、且重渲染成本很高的子组件时，提取+useCallback包裹拿到稳定引用，可以避免子组件无意义的重渲染，这时候才会产生实际的性能收益。

不要为了「优化性能」无脑提取所有内联函数：一方面无意义的提取会让代码变啰嗦，另一方面滥用useCallback还需要额外维护依赖项，依赖写错了反而会拿到过期的闭包值，平白增加bug概率。

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