React 性能优化双子星：useMemo 与 useCallback 的正确打开方式

"React 组件重渲染，就像你每次回家都要重新装修一遍------除非你知道怎么用 useMemo 和 useCallback 把门焊死。"

在大厂前端面试中，"如何优化 React 性能？"几乎是必问题。而 useMemo 与 useCallback，正是 React 官方钦定的性能优化"双子星"。

但很多人用错了------不是"用了没效果"，就是"过度优化反被优化"。

今天，我们就从两段真实代码出发，深入原理、拆解陷阱、直击面试考点，带你彻底掌握这两个 Hook 的正确使用姿势。

🔥 问题引入：为什么我的子组件总在"无意义"地重渲染？

想象一个典型场景：

父组件维护两个状态：count（计数器）和 num（另一个无关状态）
子组件只依赖 count 和一个点击回调
但当你点击"+1 num"按钮时，子组件居然也重新渲染了！

这不仅浪费性能，还可能触发不必要的副作用（比如重复请求、动画重置等）。问题出在哪？

答案就藏在 JavaScript 的 引用相等性（Reference Equality） 机制里。

🧠 核心概念：React 的"浅比较"与 `memo` 的局限

React 函数组件默认会在父组件更新时整体重执行 。为了优化，我们常用 React.memo 包裹子组件：

javascript 复制代码

const Child = memo(({ count, handleClick }) => { ... })

memo 的作用是：仅当 props 的引用发生变化时，才触发子组件重渲染 。它内部使用的是浅比较（shallow comparison） 。

但问题来了：

javascript 复制代码

const handleClick = () => { console.log('click'); }
// 每次父组件重渲染，handleClick 都是一个全新的函数！

在 JavaScript 中，即使两个函数逻辑完全一致，它们的引用也不相等：

scss 复制代码

() => {} === () => {} // false

于是，哪怕 count 没变，只要父组件因 num 更新，handleClick 引用变了 → memo 判定 props 变了 → 子组件重渲染 ❌

这就是 useCallback 登场的理由。

🔍 源码逐行解析：`useCallback` 如何"冻结"函数引用

看第一段代码的关键部分：

ini 复制代码

const handleClick = useCallback(() => {
  console.log('click');
}, [count]);

✅ 功能目的

缓存函数引用，仅在依赖项（如 count）变化时生成新函数。

⚙️ 执行上下文

useCallback(fn, deps) 本质是 useMemo(() => fn, deps) 的语法糖。
React 会将该函数缓存在当前 Fiber 节点的 hooks 链表中。
下次渲染时，若依赖数组浅比较相等，则直接返回上一次缓存的函数引用。

🎯 依赖数组 `[count]` 的深意

这里有个经典陷阱 ：虽然当前 handleClick 体内没用到 count，但如果未来你添加了类似 console.log(count) 的逻辑，却忘了更新依赖，就会掉进 Stale Closure（闭包过期） 的坑------函数始终捕获旧的 count 值。

💡 最佳实践：依赖数组必须包含函数体内所有用到的响应式变量（state / props / 其他 callbacks）。

🔄 对比：不用 `useCallback` 的后果

javascript 复制代码

// ❌ 每次父组件渲染都新建函数 → 引用变化
const handleClick = () => { ... }

// ✅ 引用稳定 → 子组件可安全使用 memo
const handleClick = useCallback(() => { ... }, [])

🧮 `useMemo`：不只是"缓存计算"，更是"避免副作用"

再看第二段代码：

ini 复制代码

const filterList = useMemo(() => {
  return list.filter(item => item.includes(keyword))
}, [keyword])

❓ 为什么需要 `useMemo`？

因为：

arduino 复制代码

const filterList = list.filter(...) // 每次组件重渲染都会执行！

即使 keyword 没变，只要 count 更新，整个组件函数重跑 → filter 重执行 → 控制台疯狂打印 "filter 执行"。

useMemo 的作用 ：仅当 keyword 变化时，才重新计算过滤结果。

⚠️ `includes("")` 的隐藏行为

注意："apple".includes("") 返回 true！这意味着当输入框为空字符串时，所有列表项都会匹配------这通常是预期行为，但务必心中有数。

💰 昂贵计算的救星：`slowSum`

scss 复制代码

const result = useMemo(() => slowSum(num), [num]);

slowSum 是一个 O(n) 的耗时操作（千万次循环）。若不用 useMemo，每次 count 改变都会触发一次卡顿级计算，UI 直接"冻住"。

在这里，useMemo 不仅是优化，更是用户体验的保障。

🤔 深度追问：`useCallback` 和 `useMemo` 真的免费吗？

不，它们也有成本：

内存开销：React 需要存储缓存值或函数；
比较开销：每次渲染都要对依赖数组做浅比较；
心智负担：错误的依赖可能导致 bug 或内存泄漏。

✅ 何时该用？一张表说清楚

场景	是否推荐
传递给 `memo` 子组件的回调函数	✅ 必用 `useCallback`
昂贵计算（大数据过滤、复杂公式等）	✅ 必用 `useMemo`
简单计算（如 `a + b`）	❌ 不要用，得不偿失
函数未传递给子组件	❌ 通常无需缓存

📌 阿里 P7 面试官常问 ："useMemo 能否用于创建对象或数组以避免子组件重渲染？"
答：可以，但更推荐将整个 props 对象用 useMemo 包装，或结合 React.memo + useCallback 组合拳。

🧩 知识拓展：背后的 React 渲染机制

1. React 的协调（Reconciliation）过程

组件更新 → 生成新的 React Element 树 → 与旧树 diff → 找出最小变更 → 更新 DOM。
若子组件被 memo 包裹且 props 引用未变 → 跳过该子树的 diff，性能提升显著。

2. 闭包陷阱（Stale Closure）

scss 复制代码

const handleClick = useCallback(() => {
  console.log(count); // 如果依赖是 []，永远输出初始值 0！
}, []); // ❌ 错误依赖

这是典型的 stale closure 问题。React 官方甚至为此推出了 eslint-plugin-react-hooks 插件自动检测依赖缺失。

3. `useCallback` vs `useMemo` 的本质

scss 复制代码

// useCallback 就是 useMemo 的特例
useCallback(fn, deps) ≡ useMemo(() => fn, deps)

所以，useCallback 并非魔法，只是语义更清晰、意图更明确。

💼 面试关联：大厂高频考点

公司	面试题	考察点
字节	"`useMemo` 和 `useEffect` 有什么区别？"	缓存 vs 副作用执行时机
腾讯	"如何避免子组件不必要的渲染？"	`memo` + `useCallback` + 依赖管理
阿里	"`useCallback` 能解决所有性能问题吗？"	理解其局限性（如无法阻止父组件自身重渲染）
美团	"依赖数组写错会有什么后果？"	stale closure / 内存泄漏 / 逻辑错误

答题思路建议：先描述业务场景 → 引出性能问题 → 介绍工具方案 → 分析底层原理 → 指出常见陷阱 → 给出工程化最佳实践。

✅ 总结与最佳实践

useCallback 用于缓存函数引用 ，配合 React.memo 阻止子组件无效重渲染；
useMemo 用于缓存计算结果，避免昂贵操作或副作用重复执行；
依赖数组必须完整且准确 ，强烈建议启用 ESLint 的 react-hooks/exhaustive-deps 规则；
不要过度优化：简单计算、未传递的函数无需缓存；
性能优化的前提是性能分析：先用 React DevTools Profiler 定位瓶颈，再针对性优化。

React 性能优化双子星：useMemo 与 useCallback 的正确打开方式