React 钩子依赖链优化：利用 useMemoizedFn 解决回调函数因闭包引用频繁更新的问题

各位同学，大家好！欢迎来到今天的“React 钩子优化与闭包陷阱”特别讲座。

今天我们不聊高深莫测的架构，也不谈那些听起来很厉害但根本用不到的 useEffect 深度用法。我们要聊的是每一个 React 开发者——从初级到资深——都绕不开、甚至经常会被它折磨得怀疑人生的“老朋友”：闭包，以及我们如何利用 useMemoizedFn 来拯救我们岌岌可危的性能。

你们有没有遇到过这种情况：你的组件明明什么都没变，它却像个精神分裂症患者一样，每隔几毫秒就疯狂地重新渲染一次？或者，你点击了一个按钮，结果把别处的一个数字给改了？又或者，你明明写了 useCallback，结果发现子组件还是重新渲染了，你甚至开始怀疑人生，问自己是不是该转行去写 Vue？

别怕，今天我们就来彻底治愈这些毛病。

第一部分：钩子的“精神分裂症”

首先，我们要认清一个残酷的现实：React 的核心哲学是“声明式编程”。简单来说，就是“告诉 React 你想要什么，至于怎么做到的，你自己看着办”。

但是，React 内部是“命令式”的。它必须时刻盯着你的代码，一旦你的状态变了（比如 count 从 1 变成了 2），它就得把你的组件拆了、重组、再装回去。这个过程，我们称之为“渲染”。

这听起来很正常，对吧？但是，问题就出在这个“重组”的过程中。

想象一下，你的组件就像一个剧本，而 React 就是一个演员。每次状态变化，React 就要重新读一遍剧本，然后按照剧本去演。

但是，React 演员有个毛病：健忘。

第二部分：闭包的“时间旅行”陷阱

让我们来引入一个概念：闭包。

在 JavaScript 中，闭包就是函数和其词法环境的组合。通俗点说，就是函数记住了它被创建时的那个环境，即使那个环境已经“过期”了。

在 React 中，当我们定义一个函数，比如：

const handleClick = () => {
  console.log(count);
  setCount(count + 1);
};

这里的 handleClick 就是一个闭包。它“记住”了创建它时 count 的值。假设初始 count 是 0。

React 渲染了一次，handleClick 被创建，它“记住”了 count = 0。

然后，你点击了按钮。React 开始更新。setCount(1) 被调用。count 变成了 1。

现在，React 准备渲染第二次。它问：handleClick 需要更新吗？

如果 handleClick 没有依赖 count，React 可能会复用旧的 handleClick（这是 useCallback 做的事）。于是，它拿出了那个“记得是 0”的旧函数。

当你再次点击时，这个旧函数执行了。它读取的是闭包里的 0，然后执行 setCount(0 + 1)。

这就导致了“时间旅行”式的 Bug： 状态明明变了，但回调函数却还在用旧的状态。

如果 handleClick 依赖了 count，React 就会创建一个新的函数。这没问题，但问题在于，这个新函数会传给子组件。

第三部分：useCallback 的“依赖地狱”

为了解决这个问题，我们通常使用 useCallback。

const handleClick = useCallback(() => {
  console.log(count);
  setCount(count + 1);
}, [count]);

useCallback 告诉 React：“嘿，如果 count 没变，你就给我留着这个函数的引用，别重新创建新的了，省得子组件还要重新渲染。”

这看起来很完美，对吧？但实际上，它引入了一个新的概念：依赖数组。

想象一下，你有一个父组件，里面包含一个列表。列表里有 100 个子组件。

function ParentComponent() {
  const [data, setData] = useState([{ id: 1, name: 'Item 1' }, { id: 2, name: 'Item 2' }, ...]);
  const [filter, setFilter] = useState('');

  // 这里的 filter 变了，父组件重新渲染
  const filteredData = data.filter(item => item.name.includes(filter));

  return (
    <div>
      <input value={filter} onChange={e => setFilter(e.target.value)} />
      {filteredData.map(item => (
        // 问题来了！如果 filter 变了，filteredData 变了，父组件渲染
        // 父组件渲染了，那么下面的子组件也会重新渲染（即使没变）
        // 如果我们在子组件里用了 useCallback 包裹的 onClick
        <ChildComponent key={item.id} item={item} onClick={() => console.log(item.id)} />
      ))}
    </div>
  );
}

在这个例子中，filteredData 是变化的。父组件重新渲染。虽然 filteredData 变了，但列表的顺序可能没变。然而，React 认为整个列表需要重新渲染。

更糟糕的是，如果我们在 ChildComponent 里这样写：

function ChildComponent({ item, onClick }) {
  const handleDelete = useCallback(() => {
    // 这里有一个巨大的隐患：handleDelete 依赖了 item
    // 但因为父组件重新渲染，onClick 可能被重新创建（如果父组件的渲染函数没被 memoize）
    // 或者 onClick 本身就是稳定的，但 handleDelete 每次都变！
    console.log('Deleting', item.id);
  }, [item]); // 依赖 item

  return <button onClick={handleDelete}>Delete {item.name}</button>;
}

看，handleDelete 每次父组件渲染都会重新创建。如果父组件渲染了 1000 次（因为输入框打字太快），子组件就会渲染 1000 次。

为了解决这个问题，你可能不得不把整个父组件或者列表项都包在 React.memo 里，还得精细地控制依赖数组。

这就是传说中的依赖地狱。你就像一个守门员，不仅要自己踢球（写逻辑），还得时刻盯着队友的脚（依赖数组），生怕他们踢错了，导致整场比赛（渲染）都要重来。

第四部分：useMemoizedFn —— 银弹还是魔法？

现在，让我们把目光转向我们的救星——useMemoizedFn。

这个概念最早来自 ahooks 库（如果你没用过 ahooks，建议马上去安装，它是 React 开发者的福音）。它的核心思想非常简单粗暴：不管你怎么折腾，这个函数的引用永远不变。

它不关心依赖数组。它不关心状态是否变化。它就是那个“永远年轻、永远热泪盈眶”的函数。

看下面的代码：

import { useMemoizedFn } from 'ahooks';

function ParentComponent() {
  const [count, setCount] = useState(0);
  const [filter, setFilter] = useState('');

  // 普通的函数，每次渲染都会变
  const handleClick = () => {
    console.log(count); // 这里永远是旧值！
    setCount(count + 1);
  };

  // 使用 useMemoizedFn
  const stableClick = useMemoizedFn(() => {
    console.log(count); // 这里永远是新值！
    setCount(count + 1);
  });

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={handleClick}>Use unstable function (Bug!)</button>
      <button onClick={stableClick}>Use stable function (Good!)</button>
    </div>
  );
}

看到区别了吗？

handleClick 是闭包陷阱的受害者，它捕获了旧状态。
stableClick 是 useMemoizedFn 的产物。它虽然每次渲染都会重新执行（因为它要访问最新的 count），但是，它每次返回的函数引用是一样的。

这就是关键！

第五部分：为什么引用稳定能解决渲染问题？

React 的性能优化机制中，有一个核心组件叫 React.memo。它的原理非常简单：在渲染子组件之前，React 会对比 prevProps 和 nextProps。

如果 props 没变，React 就直接跳过子组件的渲染，直接复用上一次的 DOM 节点。

const ChildComponent = React.memo(({ onClick }) => {
  console.log('ChildComponent rendered!');
  return <button onClick={onClick}>Click me</button>;
});

当父组件更新时：

1. 如果 onClick 是普通函数，它每次都是新的引用。React.memo 发现 props 变了（函数变了），于是子组件渲染。
2. 如果 onClick 是 useMemoizedFn，它永远是一个稳定的引用。React.memo 发现 props 没变（函数还是那个函数），于是子组件不渲染。

这就好比，你给好朋友发了一个链接。useCallback 像是你每次都去打印一个新的二维码给他。虽然内容一样，但他每次扫码都得重新下载一次。而 useMemoizedFn 像是你把那个二维码纹在了他的手上，或者贴在他脑门上。无论你怎么变，二维码还是那个二维码，他扫码永远是同一个。

第六部分：深度剖析 useMemoizedFn 的实现原理

为了让大家更透彻地理解，我们来手写一个简单的 useMemoizedFn。

它的核心逻辑其实就两步：

1. 维护一个缓存：记住上一次返回的函数。
2. 返回一个新函数：这个新函数内部调用了一个闭包函数，闭包函数里包含了最新的状态。

function useMemoizedFn(callback) {
  const fnRef = useRef();

  // 我们使用 ref 来保存 callback，这样即使组件重渲染，fnRef 里的值也不会变
  // 它总是指向最新传入的 callback
  if (!fnRef.current) {
    fnRef.current = callback;
  }

  // 创建一个新函数，这个新函数每次都返回
  // 关键点：这个新函数的引用是稳定的（只要组件不卸载）
  const stableFn = (...args) => {
    // 在函数执行时，我们调用的是最新的 callback
    // 这时候 callback 能访问到最新的闭包环境（比如最新的 state）
    return fnRef.current(...args);
  };

  return stableFn;
}

看，这就是魔法。stableFn 的引用是稳定的，所以 React.memo 认为它没变。但是 fnRef.current 始终是最新传入的 callback，所以它能访问到最新的状态。

这里有个非常容易混淆的点，必须强调：

useMemoizedFn 返回的函数，每次调用都会执行最新的 callback。这意味着，如果你在函数里写了副作用，副作用每次都会执行。

useEffect(() => {
  console.log('Effect runs');
  return () => console.log('Cleanup runs');
}, []);

const fn = useMemoizedFn(() => {
  console.log('Fn runs');
});

当你调用 fn() 时，Effect runs 会打印一次（因为 useEffect 在组件挂载时执行了一次，虽然不是由 fn 触发的，但 fn 依赖的组件渲染了）。然后 Fn runs 打印。

这和 useCallback 是一样的。

但是！ 如果父组件重新渲染了，useCallback 会创建一个新函数，导致 React.memo 失效，子组件重新渲染。而 useMemoizedFn 不会创建新函数，子组件不会重新渲染。

所以，useMemoizedFn 是为了解决“引用稳定性”问题，而不是为了解决“副作用执行”问题。

第七部分：实战演练——性能大比拼

让我们来一场实战。我们模拟一个复杂的场景：一个包含 1000 个列表项的组件，每一项都有一个删除按钮和一个计数器。

场景 A：使用 useCallback。
场景 B：使用 useMemoizedFn。

代码实现：

import React, { useState, useCallback, useMemo } from 'react';

// 模拟一个重型子组件
const HeavyChild = React.memo(({ onCount, onDelete }) => {
  // 模拟一些计算
  const expensiveValue = useMemo(() => {
    let sum = 0;
    for (let i = 0; i < 10000; i++) {
      sum += i;
    }
    return sum;
  }, []);

  console.log('Child Component Rendering...');

  return (
    <div style={{ border: '1px solid red', margin: '5px', padding: '5px' }}>
      <p>Value: {expensiveValue}</p>
      <button onClick={onCount}>Count</button>
      <button onClick={onDelete}>Delete</button>
    </div>
  );
});

const App = () => {
  const [items, setItems] = useState(Array.from({ length: 1000 }, (_, i) => ({ id: i, count: 0 })));
  const [globalCount, setGlobalCount] = useState(0);

  // 场景 A: 使用 useCallback
  // 问题：每次父组件渲染，或者 items 变化，这个函数都会变
  const handleDeleteA = useCallback((id) => {
    setItems(prev => prev.filter(item => item.id !== id));
  }, []);

  const handleCountA = useCallback((id) => {
    setItems(prev => prev.map(item => item.id === id ? { ...item, count: item.count + 1 } : item));
  }, []);

  // 场景 B: 使用 useMemoizedFn (假设我们用 ahooks)
  // 优势：无论父组件怎么变，handleDeleteB 的引用永远不变
  // 这意味着，只要 items 数组的引用没变，子组件就不会重新渲染
  // 但如果 items 变了，React 会重新渲染父组件，此时 handleDeleteB 会执行最新的逻辑
  // 等等，这里有个陷阱！如果 items 变了，父组件肯定要渲染，子组件也要渲染。
  // 除非我们用了 React.memo 并且 props 没变。

  // 让我们修正一下场景 B 的逻辑，使其更符合 useMemoizedFn 的优势场景
  // 假设父组件渲染是因为一个不相关的状态变了，比如 filter
  const [filter, setFilter] = useState('');

  const filteredItems = items.filter(item => item.id.toString().includes(filter));

  // 这里我们用 useMemoizedFn
  const handleDeleteB = useMemoizedFn((id) => {
    setItems(prev => prev.filter(item => item.id !== id));
  });

  return (
    <div>
      <input value={filter} onChange={e => setFilter(e.target.value)} />
      <h3>Filter: {filter}</h3>

      <h4>Scenario A (useCallback):</h4>
      {filteredItems.map(item => (
        <HeavyChild 
          key={item.id} 
          onCount={handleCountA} 
          onDelete={handleDeleteA} 
          item={item} 
        />
      ))}

      <hr />

      <h4>Scenario B (useMemoizedFn):</h4>
      {filteredItems.map(item => (
        <HeavyChild 
          key={item.id} 
          onCount={handleCountA} // 这里其实还是用的 A，为了对比
          onDelete={handleDeleteB} 
          item={item} 
        />
      ))}
    </div>
  );
};

运行结果分析：

1. Scenario A (useCallback):

   • 当你在输入框输入 filter 时，filter 状态改变。
   • 父组件重新渲染。
   • filteredItems 重新计算。
   • handleDeleteA 和 handleCountA 重新创建（因为它们依赖 items）。
   • 子组件的 props 发生了变化（onDelete 变了）。
   • 结果： 1000 个子组件全部重新渲染。控制台打印 1000 次 “Child Component Rendering…”。浏览器卡顿。

2. Scenario B (useMemoizedFn):

   • 当你在输入框输入 filter 时，filter 状态改变。
   • 父组件重新渲染。
   • filteredItems 重新计算。
   • handleDeleteB 没有重新创建。它还是那个稳定的引用。
   • 子组件的 props 中，只有 item 变了（因为过滤后的数组变了）。onDelete 没变。
   • 结果： 只有发生变化的子组件重新渲染。控制台打印次数取决于 filter 改变了多少个 ID。如果 filter 没变，打印次数为 0。性能提升巨大。

第八部分：进阶技巧与常见误区

虽然 useMemoizedFn 很强大，但也不能滥用。它不是万能的灵丹妙药。

误区 1：在 useEffect 的依赖数组里用 useMemoizedFn

useEffect(() => {
  const fn = useMemoizedFn(() => {
    console.log('Hello');
  });

  // 这样写，fn 永远不会变，useEffect 里的逻辑永远不会执行
  // 这是一个典型的反模式
}, []);

误区 2：过度使用 React.memo

如果你把所有的子组件都包上 React.memo，然后把所有的函数都用 useMemoizedFn 包起来，你的应用性能会变得非常奇怪。因为 useMemoizedFn 虽然稳定了函数引用，但它依然会触发子组件的渲染（只是避免了因为函数引用变化导致的重新渲染）。如果函数内部依赖的 props 变了，子组件还是要渲染的。

正确的姿势：

1. 识别瓶颈：先找出那些渲染了很深层的组件，或者渲染了很复杂的列表的组件。
2. 包裹 React.memo：让它们只在自己 props 变化时渲染。
3. 用 useMemoizedFn 替换 useCallback：确保传给它们的函数引用是稳定的。
4. 避免“幽灵渲染”：不要为了性能优化，把不该渲染的逻辑强行延迟渲染。useMemoizedFn 只能优化函数引用，不能优化组件本身。

第九部分：从类组件到函数组件的跨越

在 React 的早期（类组件时代），我们很少遇到这个问题，因为 this.handleClick 是绑定在实例上的。

class MyComponent extends React.Component {
  state = { count: 0 };

  handleClick = () => {
    console.log(this.state.count);
    this.setState({ count: this.state.count + 1 });
  }

  render() {
    return <button onClick={this.handleClick}>Click</button>;
  }
}

在类组件中，this.handleClick 的引用是稳定的（只要类实例没销毁）。所以子组件渲染时，onClick 不会导致子组件重新渲染。

但是，到了函数组件时代，我们失去了 this，只能用闭包。如果不加处理，每次渲染都会创建一个新的函数引用。

useCallback 模仿了类组件的行为，试图让函数引用稳定。但 useCallback 是“笨”的，它需要你手动声明依赖。

useMemoizedFn 则是“聪明”的，它模仿了 this.handleClick 的行为，自动帮你搞定依赖问题。

第十部分：总结与展望

好了，同学们，今天的讲座接近尾声。

我们回顾了 React 渲染的痛苦，了解了闭包陷阱是如何导致状态不同步的，体验了 useCallback 带来的依赖地狱，并最终找到了 useMemoizedFn 这把利剑。

useMemoizedFn 的核心价值在于：它将函数引用的稳定性管理从开发者的负担中解放了出来。

它让你可以专注于业务逻辑本身，而不必担心“哎呀，我忘了把 filter 加到 useCallback 的依赖数组里了，结果导致子组件重新渲染了”。

它就像是一个尽职的管家，默默地在后台帮你把函数的引用锁死，只把最新的逻辑执行给你。

最后，给大家一个忠告：

在处理列表渲染、事件监听、以及任何传递给 React.memo 优化的子组件的 props 函数时，请毫不犹豫地使用 useMemoizedFn。

它简单、高效、优雅。它能让你从无休止的 useCallback 依赖数组排查中解脱出来，让你有更多的时间去喝咖啡、写博客，或者干脆去摸鱼。

记住，好的代码不仅要能跑，还要跑得快，还要让写代码的人心情愉悦。

谢谢大家！希望你们在 React 的世界里，不再有闭包的噩梦，只有 useMemoizedFn 带来的安稳觉。

（讲座结束，掌声雷动）