为什么React的useCallback不能始终返回同一引用？自研实现有何问题？

不少开发者（包括本提问的作者）都对React内置useCallback的设计存在困惑：为什么它在依赖数组的任意一项更新时，就一定会返回新的函数引用？这种行为会触发大量本来可以被React.memo()规避的无意义重渲染，反而抵消了memo的优化价值。

基于这个痛点，提问者编写了如下自定义版本的useCallback，希望替代React内置实现：

export function useCallback(callback) {
    const callbackRef = useRef();
    callbackRef.current = callback;
    return useState(() =>
        (...args) => callbackRef.current(...args)
    )[0];
}

这个实现的设计思路非常直接：

• 用ref容器始终持有最新传入的回调函数，每次组件渲染时都把最新的回调同步到ref上
• 用useState惰性初始化一个永远不变的代理函数，代理函数本身不持有任何闭包状态，执行时永远从ref里取最新的回调运行
• 最终从hook返回的函数引用从组件挂载到卸载全程保持不变，既免去了手写依赖数组的心智负担，又能从根源上避免React.memo()因为引用变化触发的无意义重渲染

提问者最初认为这个实现只有一个明确的行为差异：在setTimeout这类延后执行回调的场景下，因为ref永远存的是最新的回调，所以延后触发的回调不会拿到它创建时的闭包旧值，而是会拿到触发时刻的最新状态值。在他看来，这本来就是符合直觉的预期行为，除此之外没有其他缺点，完全可以替代内置的useCallback。他还提到，这个实现的功能和React团队之前提出的RFC中、计划推出的内置HookuseEvent完全一致。

这个自实现版本存在的实际问题 #

• 渲染阶段写ref的副作用时序问题
  这个版本直接在组件渲染的函数执行阶段给callbackRef.current赋值，本质是在渲染流程中产生了副作用写操作，完全不符合React对ref更新的时序要求。而官方计划的useEvent实现会严格把ref的更新放在React的提交阶段（也就是DOM更新完成之后）执行，避免在渲染过程中产生副作用。
• 并发渲染模式下的状态错乱风险
  在React 18的并发渲染场景中，组件渲染是可以被暂停、丢弃、重新执行的。如果在渲染阶段直接给ref赋值，很容易出现ref被某次被丢弃的渲染流程意外覆盖的情况：比如某次未最终提交的渲染已经把ref更新成了本次渲染的回调内容，后续真正提交到界面的渲染拿到的ref值反而来自被丢弃的流程，出现难以排查的状态不一致。
• Strict Mode开发环境兼容问题
  React开发环境下的Strict Mode会故意把组件渲染函数执行两次，用来检测不符合规范的副作用。这个版本在渲染阶段直接写ref的逻辑，在Strict Mode下会出现ref赋值的时序冲突，甚至可能出现已写入的值被意外覆盖的问题，和开发环境的检测逻辑不兼容。

本质的定位差异 #

很多人会把这个实现和内置的useCallback做功能对比，但二者的设计目标从一开始就不重合：

• 内置useCallback的核心价值是让函数引用和它依赖的闭包内容绑定：当依赖变化时返回新引用，本质是为了让下游的React.memo能感知到“这个函数的关联状态已经变化，对应的渲染逻辑需要同步更新”，从来不是为了提供一个永恒不变的函数引用。
• 这个自实现版本的核心目标是返回一个永远不变的函数引用，不管它内部关联的状态怎么变化。它本质是民间版的useEvent实现，根本就不应该完全替代内置useCallback的所有使用场景——如果你需要让回调和创建时的闭包值绑定，那这个实现的行为就是不符合预期的。

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