使用 useMemo 两年后我才敢说真正读懂了它。最开始接触 React Hooks 那阵子我被一个性能问题折腾得不轻一个商品列表页顶部有一个搜索框用户每敲一个字下面的筛选结果和十几个子组件就整体抖一下。打开 DevTools 看到火焰图输入框一变化整棵组件树都在重新渲染。当时我第一时间想到的解决方案就是 useMemo给筛选逻辑和数据计算统统包上缓存页面确实明显顺滑了。可说实话当时我并不理解它为什么有用只是照着网上的例子套。直到后来踩了缓存失效、依赖漏写、内存开销这些坑又把 React 的渲染调度源码翻了翻才自认对 useMemo 有了真正的理解。这篇文章不打算从文档概念讲起而是直接把这些年使用 useMemo 的实战经验、原理分析和踩坑记录整理出来希望能帮你少走弯路。1. 为什么需要 useMemo从一次页面卡顿说起1.1 一个最常见的性能浪费场景先还原一下我最初遇到的那个场景。页面结构大致是这样顶部一个受控输入框中间一个列表组件列表组件往下还挂着好几个展示型子组件。function ProductPage({ products [] }) { const [keyword, setKeyword] useState(); const filtered products.filter((p) p.name.toLowerCase().includes(keyword.toLowerCase()) ); const totalPrice filtered.reduce((sum, p) sum p.price, 0); return ( div input value{keyword} onChange{(e) setKeyword(e.target.value)} / ProductList list{filtered} totalPrice{totalPrice} / /div ); }这个写法的痛点在于filtered和totalPrice是每次渲染都会重新计算的。用户每敲一个字符哪怕结果集和金额完全没变所有计算都要从头再来一遍。当products有几万条或者子组件本身的渲染代价较高时卡顿一下就很容易理解了。很多人第一反应是这不就是 useMemo 该上场的场景吗对也不对。说它对是因为这里的派生数据确实是计算密集型操作适合缓存说它不对是因为如果仅仅为了避免几万次数组遍历很多时候写一个合理的组件拆分或者调整数据流就能解决不一定要请出 useMemo。我用这个例子是想说明 useMemo 的核心定位它缓存的是一个函数的计算结果用来告诉 React“在依赖没变的情况下别重新算直接给我上次的结果”。1.2 useMemo 的本质缓存值不是缓存组件这里要特别澄清一个高频误区。很多人以为 useMemo 能把整个组件“冻结”住用了它组件就不会重新渲染。这是不对的。函数的重新渲染是另一套机制useMemo 管不到。它真正做的事情是在渲染过程当中如果依赖数组里的每一项都和上一次渲染时相同就跳过内部函数的执行直接返回上一次保存的结果。用一句不太严谨但非常好记的话来理解useMemo 不是给组件“贴了免渲染符”而是给某个计算过程“挂了免算牌”。组件该重新渲染还是会重新渲染只是重渲染期间那些昂贵的派生计算能跳过就跳过了。1.3 useMemo、React.memo 和 useCallback 三兄弟的分工新手最容易懵的问题是这几个东西都是搞性能优化的到底要不要一起上我的理解是这样useMemo 缓存计算结果影响的是“渲染期间做计算”的耗时。useCallback 缓存函数引用本质上就是 useMemo 的一种特例只是把它用在函数类型的返回值上。React.memo 是 React 内置的组件记忆化工具它给函数组件加一层判断如果 props 没变就跳过这次重新渲染。这三者平时经常配合使用。最典型的组合拳是父组件 re-render 时需要保证传给子组件的对象、数组、函数引用都不变同时子组件外层套上 React.memo这样子组件才有可能跳过这次渲染。如果父组件每次重新执行时都创建新的对象字面量React.memo 的浅比较直接失效那 useMemo 的“免算牌”在子组件这层也就浪费了。2. useMemo 的执行机制与依赖判断逻辑2.1 缓存如何建立、命中与失效要真正理解 useMemo必须把 React 组件的渲染流程和缓存生命周期弄清楚。React 函数组件每次渲染本质上是“执行一次函数”。组件函数执行时React 会建立一棵由各个 Hook 节点组成的链表。useMemo 在链表上会登记两个核心信息上一次保存的 memoizedValue记住的值以及上一次渲染时的依赖数组。当组件重新渲染并再次执行到同一个 useMemo 时React 会拿着新的依赖数组和上一次保存的依赖数组逐项做比较比较规则是Object.is。全部相等就称“命中缓存”直接返回 memoizedValue内部函数根本不会执行只要有一项不等就重新执行内部函数把结果覆盖到 memoizedValue 上同时更新依赖数组记录。这个机制决定了两个使用要点第一依赖数组必须把内部函数用到的外部变量全部列全第二依赖数组里每一项的引用稳定性也会影响缓存命中率。前者是正确性问题后者是性能问题。2.2 依赖数组的完整性与闭包陷阱在 useMemo 里踩过最深的一个坑就是闭包捕获了过期变量。写下面这类代码时特别容易翻车function PriceSummary({ products, discountRate }) { const total useMemo(() { const base products.reduce((sum, p) sum p.price, 0); return base * discountRate; }, [products]); // 漏了 discountRate return div{total}/div; }依赖数组里只写了products漏掉了discountRate。当discountRate从 0.8 改成 0.9 时useMemo 一看products没变直接返回缓存的旧结果页面金额纹丝不动。这种 bug 经常在代码 review 时看不出来因为逻辑本身没错运行结果却错了。更气人的是这种问题往往不会稳定复现。因为只要父组件重渲染时传进来的是同一个products引用它就不重新计算。如果你后续又触发了别的状态变化导致引用重建它又会“莫名其妙地正常一阵子”。排查这类问题最笨但最有效的办法就是检查 useMemo 内部函数里出现的每一个变量是否都出现在依赖数组里。除了初始化和内部创建的变量其余的一律要列进去。2.3 对象引用稳定性useMemo 的第二价值我在实际项目里慢慢发现useMemo 最大的收益很多时候不是省计算而是稳定对象引用。React 里有一条隐藏规则每次渲染中新创建的对象、数组、函数引用一定不相同。比如下面这种写法const detailConfig { source: product_detail, openNewWindow: true };每次 render 都会新建一个对象哪怕内容完全一样引用也不同。把它传给被 React.memo 包裹的子组件时子组件每次都会因为 props 的引用变化而重新渲染。但改成下面这样const detailConfig useMemo( () ({ source: product_detail, openNewWindow: true }), [] );只要组件没被卸载这个引用就基本稳定React.memo 的保护才能真正生效。这个特性在配合 Context 使用时尤其关键。3. 实战案例拆解从简单派生到复杂计算3.1 场景一列表过滤、排序等派生数据回到开头的例子一个典型的 useMemo 优化方案是function ProductPage({ products [] }) { const [keyword, setKeyword] useState(); const [order, setOrder] useState(asc); const visibleProducts useMemo(() { const filtered products.filter((p) p.name.toLowerCase().includes(keyword.toLowerCase()) ); return order asc ? [...filtered].sort((a, b) a.price - b.price) : [...filtered].sort((a, b) b.price - a.price); }, [products, keyword, order]); return ProductList list{visibleProducts} /; }这里的依赖数组有三个products、keyword、order。用户在搜索框输入时只有keyword变化才会重新过滤切换排序也只重新排序。如果纯粹只是某个无关状态比如一个弹窗的开关、一个不相关的按钮点击计数发生变化导致组件重渲染visibleProducts的计算就会被完整跳过这就是缓存命中带来的直观收益。我要提醒的是这种优化成立的前提是依赖数组里的products引用稳定。如果父组件每次渲染都通过someApi.getProducts()这样的方式拿数据即使后端返回的数据内容一样如果返回的是新数组products引用也会变useMemo 照样会重新计算。所以这里的深层问题是数据来源的引用稳定性决定了 useMemo 能保住的底线而不是 useMemo 决定数据源稳定。3.2 场景二useMemo 传递稳定引用给子组件上面提到的detailConfig是这类的典型例子。再举一个更贴近实际项目的轮播图配置、图表配置、地图弹层样式等一堆不会频繁变化但每次都新建的对象全都适合用 useMemo 固定引用。尤其在表单页面中配置对象往往很长每次渲染都重建会造成大量无效的深比较与子组件重渲染。我还常见到一种滥用和误用并存的写法用 useMemo 直接返回 JSX。const renderList useMemo(() ProductList list{list} /, [list]);这个写法能减少子组件的渲染次数吗能但副作用也不小。返回 JSX 等于把渲染结果的一部分提前生成出来这会干扰 React 对组件树结构的分析和后续协调。而且当这段 JSX 被直接写进父组件 return 中时它其实已经不属于常规的组件层级了任何依赖父组件上下文的逻辑都会变得不可预期。我的建议是JSX 尽量交给组件的正常渲染流程缓存对象、函数、计算结果都可以缓存 JSX 这种操作最好别碰。3.3 场景三复杂计算与数据处理管道遇到真正的大计算量任务时useMemo 的价值会被放大。比如一份几十万行的日志分析或者一个包含多层嵌套数据结构的转换函数。这类计算往往消耗几百毫秒甚至几秒每顿操作都重算会让页面直接失去响应。这种情况下使用 useMemo 时要注意一个调优方向把计算拆细。不要写一个特大的 useMemo把所有东西都塞进去也尽量不要重复调用多个 useMemo 做前后串联除非后一个依赖前一个的结果。拆细的好处是让依赖变化时只重算受影响的那一段。const parsedLogs useMemo(() parseRawLog(rawLogs), [rawLogs]); const stats useMemo(() computeStats(parsedLogs), [parsedLogs]); const chartData useMemo(() buildChartData(stats), [stats]);这里rawLogs变 → 重算 parse → stats 依赖了 parsedLogs也要重算 → chartData 依赖 stats还要重算所以整体上还是会全链路重算。但如果不变化三步缓存全部保留一次都不用重算。这种管道式写法在数据看板、报表系统里很常见也非常好用。真正要注意的是别把三步硬合成一步否则一旦rawLogs小范围变动却要把三步全跑一遍缓存体系就崩塌了。唯一要慎重的是如果数据量巨大useMemo 缓存的结果会长期占着内存不释放。这对于日志分析、图像处理这种临时性大对象尤其明显。后面在误用章节我会专门展开。4. useMemo 的误用清单与典型翻车现场4.1 缓存廉价计算收益为零反而增加负担滥用 useMemo 最常见的一种就是把一次加法、一次字符串拼接也包起来const fullName useMemo(() ${user.firstName} ${user.lastName}, [user]);这种写法从逻辑上没有错误但绝对没有带来性能提升反而增加了额外开销。因为每次渲染时 React 都要比较依赖数组[user]的每一项这就是一次Object.is比较而字符串拼接本身可能要花费不到一微秒。缓存带来的计算省略跟比较成本抵消之后基本都是亏的。我在项目里给团队定的一个建议基线是如果计算量连肉眼都察觉不到或者计算结果在单次渲染中只用到一次就不要加 useMemo。把 useMemo 当作普通 API 而不是性能救星能避免大量无效包装。4.2 依赖变化太频繁形同虚设的缓存还有一种场景是依赖数组里有一个每次渲染都会变化的值。最常见的是在组件内部传Date.now()、Math.random()、或者直接传了一个每次渲染都会重新创建的对象。比如const data useMemo(() heavyProcess(value), [getObj()]);getObj()每次渲染都返回新对象依赖数组自然每次都判定不相等于是缓存永远不命中内部函数每次渲染都完整执行。这种 useMemo 等于没写还平白增加了一层数组比较。遇到这种代码第一步不是优化 useMemo而是先把依赖项本身变成稳定引用通常需要把getObj()的返回值提升到组件外部或者包一层 useMemo。4.3 useMemo 里写副作用属于滥用 Hook 的方式useMemo 的函数体是在渲染期间同步执行的React 官方明确说过不允许在里面写修改外部状态、发起网络请求、操作 DOM 这类副作用。原因很简单渲染过程可能被中断、可以并发执行、甚至可能被 React 重复调用多次。如果在 useMemo 里写副作用一次看似普通的界面更新可能触发多次网络请求或者收到过期响应界面状态被带飞。正确做法是副作用统一放useEffect派生计算放useMemo。这两个 Hook 的场景完全不同。很多人分不清我给你一个最直观的口诀如果你做的东西是用来“算出一个值”的用 useMemo如果你是“因为某个值变了去干一件事”的用 useEffect。4.4 useMemo 不能作为错误的内存保护伞我见过一些业务在 useMemo 里缓存了特别大的对象比如一份完整的表格数据加上它的所有筛选状态和统计结果。这会让这些对象长期占据内存。组件卸载时这些缓存本应随之释放但如果有人把缓存挂到了组件外部或者全局状态上就会变成内存泄漏。使用 useMemo 时想清楚一点它缓存的是“上一次渲染的结果”这个结果的生命周期与组件实例绑定。不要把缓存结果再放置到组件外部的容器中。4.5 使用 useMemo 的“更新身份”陷阱另外一个非常常见的翻车现场是用 state 存储了一个对象后续使用 setState 时不小心直接修改了原来的对象引用并塞进去。比如const [filters, setFilters] useState({ category: all, price: 0 }); function updatePrice(price) { filters.price price; setFilters(filters); // 引用没变 }此时 useMemo 依赖了filters它发现引用没有变化缓存依然命中界面怎么也不会更新。这是典型的可变数据配合 React immutability 原则带来的坑。useMemo 的 Object.is 比较只能判断出“引用不同”无法感知对象内部属性的变化。所以使用 useState 更新数据时永远要生成一个新对象比如setFilters({ ...filters, price })这是 React 数据流稳定工作的根基。5. 性能收益的实证方法如何判断 useMemo 真的生效5.1 用 React DevTools Profiler 看火焰图纸上谈兵不如动手验证。React DevTools 的 Profiler 面板是我判断 useMemo 有没有生效的第一工具。操作方法很简单打开 Profiler → 点击录制按钮 → 在页面上做一次触发重渲染的操作比如在搜索框输入一个字符→ 停止录制。火焰图上会显示这次提交中哪些组件实际执行了渲染commit 重渲染哪些被 React.memo 拦截或没有调度到。如果一个组件在依赖没变的情况下还是被重新渲染了火焰图里它依然亮着这时候你就要去查 props 里哪个引用变了再回来调整 useMemo。需要注意的是Profiler 默认显示所有被调度的组件而不是所有真正执行副作用的组件。要看实际渲染的成本还需要看每个组件 rendered duration 的耗时而不是只看火焰图亮没亮。耗时高但亮得频繁的才是首要优化目标亮得频繁但耗时接近 0 的组件优化价值反而不大。5.2 单元测试与“缓存命中断言”业务代码如果不太好直接测性能可以在关键路径上写一个简单的计数器验证缓存命中逻辑let calcCount 0; function PriceTag({ products, rate }) { const total useMemo(() { calcCount 1; return products.reduce((s, p) s p.price, 0) * rate; }, [products, rate]); return span{total}/span; }当你不修改products和rate而触发无关状态更新时calcCount不应增加。一旦你发现它增加了说明依赖里混入了一个不稳定的引用或者组件本身被暴力重挂了新的 props引用。这种 low-tech 调试法在排查时往往比任何工具都直接。测试代码里最好也不要直接依赖 useMemo 内部的逻辑而是验证数据流的引用稳定性。更工程化的做法是把纯计算逻辑抽成独立函数单独做性能基准测试useMemo 只管控制“何时重算”不管“怎么算”。5.3 常见排查链路从“感觉卡”到“确认缓存失效”我每次遇到页面卡顿都不会一上来就想着加 useMemo。按下面这个顺序排查往往能定位到真正的问题先打开 Profiler确认卡顿是不是渲染耗时引起的。如果是看火焰图里哪些组件渲染耗时最长。检查最耗时的组件看它们的 props 是否有不稳定的引用每次渲染都新对象/新数组/新函数。如果是引用不稳定优先在源头解决状态提升、抽出子组件、把常量提到模块作用域、用 useCallback / useMemo 固定引用。如果引用稳定之后组件仍频繁渲染再看它内部是否有重复计算这个时候可以引入 useMemo。最后检查 useMemo 的依赖是否完整、是否稳定必要时用第 5.2 节的计数器验证。整体原则是用 useMemo 兜住“计算成本”用 React.memo useCallback useMemo 一起兜住“渲染成本”。如果只是计算成本单独上 useMemo 就够了如果是渲染成本那问题往往出在引用不稳定而不在于少了几次计算。6. 面试与代码评审中关于 useMemo 的高频讨论点6.1 面试题背后真正考察的东西如果你最近在准备 React 相关面试可能会碰到这类问题“useMemo 和 useCallback 有什么区别”“useMemo 一定会缓存吗”“useMemo 能否替代 useEffect”。这些问题表面考察 API实际考察的是对 Hooks 心智模型的理解程度。我的建议回答框架是useMemo 返回一个计算值useCallback 返回一个函数引用两者都依赖数组控制缓存更新useMemo 本质上是 useCallback 的特例。至于“会不会一定缓存”要说明 React 在这块给了自己处置余地官方文档提过 React 可以在特定条件下丢弃缓存因此不能在业务逻辑里强依赖 useMemo“一定会返回旧值”——这也再次说明依赖完整性的重要如果依赖都填全了即使缓存被丢弃重新计算也能得到正确结果逻辑仍然成立。6.2 评审时我会盯的四个雷区在代码评审里看到用了 useMemo 的提交我会下意识做四件事第一检查依赖数组是否完整。漏掉一个bug 就已经潜伏了。第二检查依赖数组里的项是否足够稳定。如果每次渲染都重建那么 useMemo 形同虚设。第三检查内部函数是否只做了计算没有副作用。第四评估这次“计算”是否真的昂贵。如果只是a b就建议去掉。这四步走完大部分 useMemo 的误用都会浮出水面。评审意见里我经常写的一句话是“这不是 useMemo 的问题是数据流的引用稳定性和组件拆分的问题。”最后说一点个人体会。useMemo 不复杂它就是一个带缓存的函数包装器但把它放到 React 整个渲染体系里你会发现它牵动着引用稳定性、渲染协调、内存占用和代码可维护性。我后来写新功能时基本已经不会刻意去想“这里要不要加 useMemo”了而是先按数据流和组件拆分把结构写清楚等 Profiler 显示确实存在计算或渲染瓶颈时再精准地把 useMemo 加到需要的地方。这种“按需优化、先测量后动手”的思路比一开始就满屏 useMemo 要可靠得多。也希望读到这里的你能在下一次性能排查时少绕一些弯路。