精读《React useEvent RFC》：在 React Hooks 中同时保持回调引用稳定与访问最新状态-平芜编程栈

文档
技术博客
教程

【免费下载链接】weekly

前端精读周刊。帮你理解最前沿、实用的技术。

项目地址：https://gitcode.com/GitHub_Trending/we/weekly

useEvent是 React 官方 RFC 提出的一种新 Hook，它精准解决了 Function Component 中一个长期存在的两难问题：既要让传给子组件的回调函数引用保持不变（保住 memo 性能），又要在每次调用时读到最新的 state。本篇以《React useEvent RFC》为骨架，结合本仓库「前端精读周刊」中关于 React Hooks 的系列解读（如精读《Function Component 入门》、精读《编写有弹性的组件》、精读《React Hooks 最佳实践》），从问题本质、近似实现到边界限制层层展开，读完你将彻底理解useEvent的设计动机、内部原理及其与useCallback、ref 方案的差异，并能判断自己的项目中是否真的需要它。

useEvent 要解决的一个核心矛盾

用一句话概括：如何同时保持函数引用不变与访问到最新状态。

借用提案里的代码，一下就能说清楚useEvent是个什么东西：

function Chat() { const [text, setText] = useState(''); // ✅ Always the same function (even if `text` changes) const onClick = useEvent(() => { sendMessage(text); }); return <SendButton onClick={onClick} />; }

onClick既保持引用不变，又能在每次触发时访问到最新的text值。为什么需要提供这样一个函数，它到底解决了什么问题，下面从最朴素的需求出发一步步展开。

问题剖析：为什么现有方案都顾此失彼

定义一个能访问到最新 state 的函数本身并不难：

function App() { const [count, setCount] = useState(0) const sayCount = () => { console.log(count) } return <Child onClick={sayCount} /> }

但sayCount函数引用每次渲染都会变化，这会直接破坏Child组件的 memo 效果，甚至引发更严重的连锁反应——当Child组件把onClick回调用在useEffect里时，引用变化会不断触发 effect 重跑。仓库另一篇精读《React Hooks 最佳实践》中就专门警告过这种场景：useEffect对外部依赖的要求极其苛刻，一旦上层传入的回调引用每次刷新都变动，就可能出现“新onChange→ effect 依赖更新 → 父级重渲染 → 新onChange”的无限循环。可见回调引用稳定性不只是性能问题，更是正确性问题。

useCallback：只能做到"依赖不变才稳定"

想要保证sayCount引用不变，第一反应是用useCallback包裹：

function App() { const [count, setCount] = useState(0) const sayCount = useCallback(() => { console.log(count) }, [count]) return <Child onClick={sayCount} /> }

但即便如此，我们仅能保证在count不变时sayCount引用不变。如果想保持sayCount引用彻底稳定，就要把依赖[count]移除，而这样一来闭包里的count永远是初始值，逻辑上引发更大问题。这正是useCallback的固有困境：依赖数组是引用稳定性与数据新鲜度的跷跷板，二者不可兼得。

countRef：能解决问题但绝不推荐

一种无奈的办法是维护一个countRef，使其值与count保持同步，在sayCount中访问countRef：

function App() { const [count, setCount] = useState(0) const countRef = React.useRef() countRef.current = count const sayCount = useCallback(() => { console.log(countRef.current) }, []) return <Child onClick={sayCount} /> }

这种代码能解决问题，但绝对不推荐，原因有二：

每个值都要加一个配套 Ref，非常冗余。一个组件若有多个 state 参与回调，就要手写同样数量的 ref 同步逻辑，样板代码成倍膨胀。
在函数内直接同步更新 ref 不是一个好主意，但写在useEffect里又太麻烦。仓库精读《useRef 与 createRef 的区别》对这一点有更严谨的论述：Function Component 的Render phase不允许做副作用操作，因为该阶段可能被 React 引擎随时取消或重做；修改 ref 属于副作用，正规的时机是Commit phase或回调函数中（已脱离 React 生命周期）。在渲染函数体里直接ref.current = value正是踩中了 render phase 副作用的禁区。

自创 useStableCallback：useEvent 的原型

另一种办法就是自创 hook，如useStableCallback，这本质上就是这次提案的主角——useEvent：

function App() { const [count, setCount] = useState(0) const sayCount = useEvent(() => { console.log(count) }) return <Child onClick={sayCount} /> }

事实上，本仓库的早期精读文章里已经出现过同思路的自定义实现，只是当时 React 官方尚未给出正式方案。比如精读《Function Component 入门》中的useEventCallback：

function useEventCallback(fn, dependencies) { const ref = useRef(null); useEffect(() => { ref.current = fn; }, [fn, ...dependencies]); return useCallback(() => { const fn = ref.current; return fn(); }, [ref]); }

这段代码的含义，就是使每次渲染的闭包中，回调函数总是能拿到最新一次 Rerender 闭包中的那个函数，所以依赖的值永远是最新的，而且函数不会重新初始化。可以看出，社区早已在实践中自发补齐了这一环，RFC 提案正是把这种被反复验证的模式收编为官方 API。

useEvent 的近似实现：需求一分为二

提案内给出了可能的实现思路：

// (!) Approximate behavior function useEvent(handler) { const handlerRef = useRef(null); // In a real implementation, this would run before layout effects useLayoutEffect(() => { handlerRef.current = handler; }); return useCallback((...args) => { // In a real implementation, this would throw if called during render const fn = handlerRef.current; return fn(...args); }, []); }

其实很好理解，我们将需求一分为二看：

既然要返回一个稳定引用，那最后返回的函数一定使用useCallback并将依赖数组置为[]。这样无论组件如何重渲染，对外暴露的都是同一个函数引用，子组件的 memo 浅比较与useEffect依赖都能稳稳通过。
又要在函数执行时访问到最新值，那么每次都要拿最新函数来执行，所以在 Hook 里使用 Ref 存储每次接收到的最新函数引用，在执行函数时，实际上执行的是最新的函数引用。

注意代码中两段注释，对应两个关键设计约束：

第一个是useLayoutEffect部分实际上要比layoutEffect执行时机更提前，这是为了保证函数在一个事件循环中被直接消费时，不可能访问到旧的 Ref 值。也就是说，官方实现中更新 ref 的时机必须尽量逼近渲染提交的瞬间，否则就会出现"值刚变完、立刻点按钮却拿到旧值"的窗口期。
第二个是在渲染时被调用时要抛出异常，这是为了避免useEvent生成的函数被渲染阶段使用，因为如果渲染期间读取的是"最新 handler 的返回值"，渲染结果就不再由 props/state 纯粹驱动，会破坏数据驱动的一致性。

值得一提的是，精读《编写有弹性的组件》中收录的社区版useEventCallback实现，恰恰用一行代码呼应了第二个约束——它把 ref 初始化为一个直接抛错的函数：

function useEventCallback(fn, dependencies) { const ref = useRef(() => { throw new Error("Cannot call an event handler while rendering."); }); useEffect(() => { ref.current = fn; }, [fn, ...dependencies]); return useCallback(() => { const fn = ref.current; return fn(); }, [ref]); }

也就是说，在 React 官方把"渲染期调用即抛错"变成内置行为之前，社区实现已经用"初始化占位函数抛错"的方式堵住了同样的漏洞，两条路线的设计意图是一致的。

精读：提案里那些值得玩味的细节

useEvent概念和实现都很简单，但提案里还有几个有意思的细节，决定了它在实际使用中的行为边界。

为什么命名为 useEvent

提案里提到，如果不考虑名称长短、完全用功能来命名的话，useStableCallback或useCommittedCallback会更加合适——它们都直白地表示"拿到一个稳定的回调函数"。但useEvent是从使用者角度来命名的：其生成的函数一般都被用于组件的回调函数，而这些回调函数通常都具有"事件特性"，比如onClick、onScroll，所以当开发者看到useEvent时，可以下意识地提醒自己正在写一个事件回调，语义还算直观。当然，缩短名称、便于记忆也是命名考量的重要因素。

值并不是真正意义上的实时

虽然useEvent可以拿到最新值，但和useCallback配合 ref 的方案还是有区别的，差异体现在下面这个例子里：

function App() { const [count, setCount] = useState(0) const sayCount = useEvent(async () => { console.log(count) await wait(1000) console.log(count) }) return <Child onClick={sayCount} /> }

await前后输出值一定是一样的：在实现上，count值仅是函数调用时的快照，所以函数内部异步等待期间，即便外部又把count改了，当前这次函数调用依然拿不到最新的count，而 ref 方案是可以做到的。在理解上，为了避免"夜长梦多"，回调函数尽量不要写成异步的——useEvent保证的是"每次调用都基于触发时的最新状态"，而不是"整个调用生命周期内始终追踪最新状态"。

useEvent 也救不了手残

如果你坚持写出onSomething={cond ? handler1 : handler2}这样的代码，那么cond变化后，传下去的函数引用也一定会变化，这是useEvent无论如何也避免不了的——它只能保证自己返回的那个函数引用稳定，却无法阻止你在使用端临时切换成另一个函数。也许解救方案是 Lint and throw error：在静态检查层面禁止在事件属性上直接写三元表达式。

其实将cond ? handler1 : handler2作为一个整体包裹在useEvent里，就能解决引用变化的问题：

const handler = useEvent(cond ? handler1 : handler2)

但除了 Lint，没有人能防止你绕过它。这提醒我们，useEvent解决的是一类写法的隐患，而不是所有引用不稳定问题的万能药。

可以用自定义 hook 代替 useEvent 实现吗？

不能。虽然提案里给了一个近似解决方案，社区里也早有功能相似的useEventCallback（见精读《Function Component 入门》与精读《编写有弹性的组件》），但自定义实现实际上存在三个问题：

在赋值 ref 时，useLayoutEffect时机依然不够提前，如果值变化后立即访问函数，拿到的会是旧值——这正是官方实现要把更新时机进一步提前、压缩到比 layout effect 更早的原因。
子组件 layout effect 在父组件之前执行，拿到的也是旧值。React 的 commit 阶段是自底向上的，父组件还没更新自己的 ref，子组件的 layout effect 却已经跑完并读到了旧引用。
生成的函数被用在渲染时并不会给出错误提示，无法像官方实现那样在渲染期调用时抛出异常，也就失去了数据驱动一致性的保障。

总结

useEvent显然又给 React 增加了一个官方概念，在结结实实增加了理解成本的同时，也补齐了 React Hooks 在实践中缺失的重要一环。回顾整个仓库的 Hooks 系列精读，无论是精读《React Hooks 最佳实践》中对useCallback包裹所有函数、开启eslint-plugin-react-hooks的规范要求，还是精读《useRef 与 createRef 的区别》中对 ref 副作用时机的严格界定，乃至精读《Scheduling in React》所描述的 Concurrent 渲染下 render phase 可被随时中断的特性，都指向同一个结论：回调的引用稳定性是 Function Component 正确性与性能的基石，而"稳定引用 + 最新状态"的组合拳必须由框架原生支持才足够严谨。无论你喜不喜欢，问题就在那，解法也给了，挺好。