讲真在React项目的性能优化环节useMemo是绕不开的一个关键Hook。尤其当你开始处理复杂列表渲染、派生数据计算或者子组件频繁重渲染问题时总会在某个夜深人静的排查现场和它碰面。useMemo的核心定位就一句话给React的大管家递一张便利贴告诉他“这个计算结果先存着如果依赖没变下次就直接拿缓存用别再算一遍了”。这篇文章我想结合自己实际项目里的使用经验把useMemo的概念、依赖数组的坑、与useCallback/useEffect之间的分工、以及一些典型的滥用误用场景一次讲透。适合两类人看一类是刚把React Hooks领悟得七七八八、开始关注渲染性能的进阶新手另一类是已经在业务里写过不少useMemo、但总觉得它时灵时不灵的“排查困难户”。不管你现在处于哪个阶段按着文章里的思路和代码走一遍应该都能对useMemo的边界有一个更清晰的认识。1. useMemo的概念本质与React渲染机制1.1 先从React的“无脑重渲染”说起要理解useMemo还得先从React组件的一个“老毛病”讲起组件内部一旦有状态变化整个函数组件都会从头到尾重新执行一遍。React不是做精确的“哪里变了才更新哪里”而是默认采取一种粗放式策略——既然你调用了setState那我就把你这个函数完完整整重新跑一次再通过虚拟DOM去比对差异最终只把真正变化的部分提交到真实DOM。这个机制在中小型项目里没有任何问题毕竟一个组件里通常没多少代码多算几次也无所谓。可一旦组件内部涉及大数组的filter、map、sort或者复杂对象的深拷贝、拼接又或者频繁触发的状态更新比如表格搜索框每次输入都setState那组件的重执行就会带来肉眼可见的卡顿。我当初踩的第一个坑就在这里。做一个客户数据后台列表有几千条记录表格组件里每次筛选条件变化都要对全量数据做一次多层过滤和排序。一开始直接写在函数体里输入搜索关键字时明显感觉敲一下卡一下。原因很简单每次keyup触发的setState都会让整个列表重新filter一遍再重新排序几毫秒的工作被几十毫秒地拉长加起来就肉眼可见了。这就是useMemo出现的前提——不是React变了而是我们需要一种机制告诉React“有些计算活儿不用每次渲染都重干”。1.2 useMemo的底层逻辑计算与缓存useMemo的英文全称是“memoize”意思是“记忆化”。它的工作机制可以类比成一个带锁的记账本只有在依赖项发生变化的时候才重新执行一遍计算函数并把新结果写进账本如果依赖项没变就直接把上次记录的结果返回给你。const memoizedValue useMemo(() computeExpensiveValue(a, b), [a, b]);注意这里的返回值不是函数而是计算结果本身。比如对数组做过滤返回的是过滤后的数组对字符串做拼接返回的是拼接后的字符串。一旦依赖项a或b发生变化React会重新执行你传入的第一个箭头函数更新返回值若a和b和上次渲染时完全一致React就直接把缓存里的结果扔给你计算函数根本不会被执行。用生活里的例子比喻一下useMemo就是一个会记账的厨子。你要吃一碗牛肉面他不一定每次都重新和面、炖肉而是先看一眼挂在墙上的小黑板——如果上面记着上周刚炖了一锅牛肉而且锅里没放进新的调料那就直接盛出来热一热端给你。这个机制的核心优势有两个一是省去了不必要的CPU计算二是让复杂对象数组、对象示例在依赖不变时保持引用稳定为下游的React.memo、useEffect依赖比较打好基础。第二个优势常常比第一个更值钱我在后面章节会详细展开。1.3 useMemo与普通“定义变量”到底差在哪新手最容易困惑的问题之一我直接在函数体里写一个变量不行吗// 普通写法 const fullList list.filter(item item.status active).sort(sortFn); // useMemo写法 const fullList useMemo(() list.filter(item item.status active).sort(sortFn), [list]);表面看两者得到的变量值可能是一样的但本质完全不同。普通写法会在组件每次渲染时都重新执行filter和sort哪怕list的值根本没变——因为组件可能因为别的state更新而重跑。useMemo写法则只在list发生变化时才重新计算其他无关的state变化根本不会触发内部计算。区别还可以体现在引用稳定性上。普通写法下每次渲染都会创建出一个全新的数组引用即使里面的内容一模一样。useMemo则不同只要依赖项不变化它返回的引用一直保持同一份。别小看这个差异它直接决定了下游React.memo子组件能否成功跳过渲染。1.4 什么时候该用什么时候不该用我见过不少团队把useMemo当柴火一样到处塞凡是变量就包一层结果性能没提上去代码倒是难读了。useMemo不是免费的它有缓存机制的内部存储成本以及依赖比对的开销如果你的计算本身就足够轻量为它套上useMemo反而更慢。适合用useMemo的场景我总结了三类计算成本高的场景比如对上千条数据进行遍历、排序、聚合或者涉及JSON序列化、正则大文本匹配。需要稳定引用的场景计算结果作为useEffect的依赖或作为props传给被React.memo包裹的子组件。高频触发的场景组件状态更新频繁计算操作每次渲染都执行的代价高。不该用的场景也很清晰普通变量赋值、简单的类型转换、一次性初始化逻辑没必要硬套。判断标准其实很朴素——先跑起来看看如果确实存在重复计算导致的卡顿再上useMemo而不是写代码的时候凭想象预判瓶颈。2. useMemo的完整语法与参数机制2.1 三个参数的各自职能useMemo接收两个参数网上有说三个严谨讲是第三个参数可忽略React官方定义其实只有两个入参第一个是“计算函数”第二个是“依赖数组”。计算函数要求是纯函数——不修改外部状态、不产生副作用、输入相同输出必然相同。依赖数组则是一组变量React会通过Object.is比较每个依赖项在上一次渲染和当前渲染之间的变化情况。const total useMemo( () items.reduce((sum, item) sum item.price, 0), [items] );依赖数组的每一项都必须真实存在于计算函数内部。如果计算函数用到了但数组没列全就属于“依赖缺失”会拿到过期缓存如果数组列了但计算函数根本没用到的变量就属于“多余依赖”会导致缓存频繁失效白白重算。为什么要求计算函数是纯函数因为在开发模式下React可以调用两次函数来检查结果一致性如果函数内部有随机数、操作了DOM、修改了外部变量不仅会产生诡异问题还会让你在排查时无从下手。2.2 依赖数组的三种形态与行为差异依赖数组的写法大体有三种每种行为差异很大。第一种传入具体的依赖数组这是最常见、最推荐的方式。比如[a, b]只有a或b变化时才重算。第二种传入空数组[]。这会告诉React“这个计算结果永远不需要重新计算”。因为依赖是空的所以useMemo只会在组件挂载阶段执行一次计算函数后续无论状态怎么变返回的都是初始那次的结果。这个模式适合用来缓存组件初始化阶段需要产生的、后续不再改变的值比如配置对象、常量列表。但要谨慎如果计算依赖了props或state空数组就会导致数据永远停在初始值。第三种不传依赖数组。这时候useMemo每次渲染都会重新执行计算函数等于完全没用到缓存机制性能上和直接写普通变量没什么区别甚至因为多了useMemo框架逻辑反而略慢。这种情况就是“乱套”基本等于没写。这里有个很实用的经验依赖数组里尽量只放必要的、最小粒度的变量。依赖越少缓存命中概率越高。2.3 缓存失效的时机与引用变化逻辑缓存失效的本质只有一个依赖项发生变化。但这里“变化”的判定方式是Object.is严格相等对基本类型就是值是否一样对引用类型就是地址是否变化。很多团队的坑就出在这里。比如依赖了一个对象const list useMemo(() rows.filter(row row.groupId filter.groupId), [filter]);如果filter对象每次渲染都是重新创建的新对象哪怕里面的groupId值完全没变useMemo也会认为它变了一次从而重算。这里我给一个经验法则依赖数组里尽量放“值”而不是放“对象”。如果必须依赖对象就先从props或state中解构出基本类型的值再放进依赖项const { groupId } filter; // 解构出基本类型 const list useMemo(() rows.filter(row row.groupId groupId), [groupId, rows]);这样groupId是字符串比较时比的是值本身就不会因为外层对象地址变化误触发计算。另外提一嘴清除缓存的问题。React官方并没有提供手动清除useMemo缓存的方法这是设计使然——依赖变化了缓存自动失效依赖没变缓存就该留着。有些场景会希望“主动重置”比如切换用户时强制清空某些计算缓存实践里通常是给组件加一个key属性让React销毁旧组件实例、挂载新实例这样useMemo也会随组件一并重新初始化。这比去折腾什么手动清除缓存要安全得多。2.4 useMemo与闭包陷阱缓存里的陈旧值说到useMemo有一个让我被坑了好几次的点闭包陷阱。因为useMemo的缓存是把计算函数执行结果存起来所以后续渲染时它记住的是“创建时那一刻”的外层变量。如果计算函数里引用了某个state但依赖数组遗漏了那个state那么当state更新后缓存里拿到的依然是旧值。比如这样一个场景function SearchResult({ keyword }) { const [page, setPage] useState(1); const result useMemo(() filterData(keyword, page), [keyword]); // page忘了写 return button onClick{() setPage(page 1)}下一页/button; }因为page没写进依赖数组翻页后页面显示的结果依然是第一页的旧数据。原因就在于useMemo闭包捕获的是首次渲染时的page值1之后每次渲染虽然page已经变成了2、3但缓存里的计算函数闭包还在用旧值。这类问题的排查思路有共性如果发现界面上的值怎么都不更新但state明明已经变化了第一反应应该是去看useMemo的依赖数组是不是漏了关键变量。我当时排查这个问题花了不少时间因为代码里确实没报错页面也没有异常警告就是数据不对最后一行一行对比依赖才找到问题。3. useMemo的典型实战应用场景拆解3.1 场景一昂贵的计算与数据转换这是useMemo最直观的使用场景。设想一个数据分析组件原始数据是一份几千条记录的大数组界面需要根据筛选条件展示汇总统计同时还要按时间排序后的列表。如果不做缓存每次复选框切换、每次输入框打字整个组件重渲染时都要重新算一遍全部数据。function Dashboard({ rawData, filters }) { const filteredData useMemo(() { return rawData.filter(item { return Object.entries(filters).every(([key, value]) item[key] value); }); }, [rawData, filters]); const statistics useMemo(() { const total filteredData.length; const avg filteredData.reduce((sum, item) sum item.value, 0) / total; return { total, avg }; }, [filteredData]); return ( div span总数{statistics.total}平均值{statistics.avg.toFixed(2)}/span {filteredData.map(item Row key{item.id} data{item} /)} /div ); }这里有个细节值得说第二个useMemo的依赖是filteredData而不是filters和rawData。因为filteredData本身已经经过了useMemo只有filters或rawData变化时它才会得到新引用所以statistics依赖filteredData是精确的、不会重算的。这套“链式缓存”方法在业务里非常实用可以逐层把大计算拆成小计算让每层只响应自己关心的依赖变化。3.2 场景二给子组件提供稳定的引用配合React.memouseMemo另外一个非常关键、甚至比“省计算”更重要的用途是引用稳定。React.memo是类组件的PureComponent在函数组件里的对应物如果props的引用与上一次对比没有变化子组件就跳过重渲染。举个例子父组件每次渲染时都会生成一个全新的对象作为props传给子组件即使对象的内容完全一致。React.memo无法判别“内容一样”它用的是浅比较看到的是引用地址变了就会认为props变了于是子组件照常重渲染。function ParentComponent({ data }) { // 没有useMemo每次渲染都新的config对象 // const config { theme: dark, pageSize: 20 }; // 使用useMemoconfig引用只在data变化时更新 const config useMemo(() ({ theme: dark, pageSize: 20 }), [data]); return ChildComponent config{config} /; }如果不加useMemo即使config内容永远没变子组件也会在父组件每次重渲染时跟着重渲染一次。加了useMemo之后只要data没变config的引用就不变React.memo包裹的ChildComponent就能成功跳过渲染性能提升非常明显。这也是为什么很多建议说给memo组件传递对象/数组/函数之类的props时一定要想办法让引用稳定下来。字符串和数字是值比较的不存在这个问题但只要是引用类型就得借助useMemo或useCallback来帮忙。3.3 场景三作为列表项批量渲染的稳定数据源列表渲染是前端开发里最常见的性能瓶颈之一。一个组件内部如果有一条长列表同时列表项的props里有计算出来的对象就会很容易引发列表项大规模重渲染。先用useMemo为每条item生成props对象再配合React.memo的列表项组件整体渲染性能会有质的提升function ItemList({ items, selectedId }) { return items.map(item { return MemoItem key{item.id} item{item} selected{selectedId item.id} /; }); } const MemoItem React.memo(function Item({ item, selected }) { return li className{selected ? active : }{item.name}/li; });在这个示例里selected是基本类型布尔值所以React.memo的浅比较没问题。如果props里需要传对象那就要像前面说的用useMemo把对象缓存起来。组合拳效果最好单独使用React.memo而不解决引用问题等于白包。3.4 场景四派生状态管理组件渲染过程里经常需要从基础state中派生出一系列“间接数据”。比如购物车场景原始state是商品清单界面需要展示总价、总件数、折扣后的金额等。这些都属于“由已有数据计算出来的数据”非常适合用useMemo进行派生。比用useEffectsetState的方式好得多——useEffect先更新一个中间变量再触发渲染会导致多一次渲染而useMemo直接在一次渲染中同步计算出结果无额外渲染。这也是业内常说的“不要在渲染途中用setState派生数据改用useMemo”。function Cart({ products }) { const subtotal useMemo( () products.reduce((sum, p) sum p.price * p.count, 0), [products] ); const discount subtotal 1000 ? subtotal * 0.1 : 0; const total subtotal - discount; // 这三个值都不需要单独useState它们都是products的派生值 }注意这里的discount和total是直接算出来的普通变量不涉及昂贵计算但也不需要useMemo因为subtotal变了它们自然会跟着变这里重点缓存的只是计算成本最高的products遍历与聚合。3.5 场景五与useEffect的依赖配合useEffect和useMemo的搭配是React Hooks里非常经典的一个组合。useEffect的依赖数组要求你传的是“稳定的值”否则如果依赖是一个每次渲染都会重新创建的引用类型useEffect会在每次渲染后都执行副作用导致死循环或频繁触发请求。举个例子组件里要根据筛选条件请求后端数据const [filter, setFilter] useState({ status: active }); const queryParams useMemo(() ({ ...filter, page: currentPage }), [filter, currentPage]); useEffect(() { fetchData(queryParams); }, [queryParams]);这里如果不加useMemoqueryParams每次渲染都是一个新对象useEffect认为依赖变了每次渲染后都会重新调用fetchData。加了useMemo后只有filter或currentPage真正变化时queryParams才会变副作用才能精准触发。但这里有一个需要重点提醒的细节在开发环境的React StrictMode下组件挂载时有些副作用模式会执行两次这不是useMemo的问题而是React故意检查你的副作用是否可重入。不要为了“消除”双执行而去禁用StrictMode正确的做法是让副作用具有幂等性。4. useMemo、useCallback与useEffect的关系与分工4.1 useCallback记忆函数本身的特殊useMemo不少开发者刚开始接触这两个Hook时会懵圈因为两者长得太像了。useCallback的记忆对象是函数本身useMemo的记忆对象是计算结果从源码角度看useCallback本质上就是useMemo的一个特例——把你的函数当作值缓存起来。// useCallback写法 const handleClick useCallback(() { setCount(count 1); }, [count]); // useMemo等价写法 const handleClick useMemo(() () { setCount(count 1); }, [count]);注意useMemo要求传入的函数必须是返回函数才会等于是缓存了那个内部函数。但日常开发里不需要这么绕能用useCallback就优先用useCallback语义更清晰。什么时候用useCallback核心场景是把函数作为props传给React.memo包裹的子组件或者把函数放进useEffect依赖数组里。因为函数是引用类型如果每次渲染都重新创建memo子组件即使内部逻辑没变也会被迫重渲染。useCallback让函数引用在依赖不变时保持不变。4.2 该用useMemo的时候别用useCallback反之亦然这里有一个常见的混用误用有人习惯在任何需要缓存的地方都套useCallback导致返回的不是计算结果而是函数调用时还得额外执行一次。比如下面这种// 错误示范本意是想要过滤后的数组 // const filtered useCallback(() list.filter(...), [list]); // 调用时还要 filtered()而且子组件收到的是一个函数而不是数组 // 正确做法想要数组就用useMemo const filtered useMemo(() list.filter(...), [list]);简单记忆想缓存“值”就用useMemo想缓存“函数”就用useCallback。这两个其实是可以互换的但从可读性角度各司其职更好。还有一个实践细节useMemo里不能放入异步操作或副作用。计算函数必须是同步纯函数如果你在useMemo里发起请求、写入localStorage之类那就是把副作用藏进了渲染过程React渲染会是不可预料的。异步数据的获取应该放useEffect里或者放到事件处理函数里。4.3 useMemo与React.memo的分工协作React.memo和useMemo虽然都带memo但干的事完全不同。React.memo是组件的缓存——当父组件重渲染时如果传给这个组件的props保持引用不变那整个子组件函数都不会被重新调用。useMemo是值的缓存——当依赖不变时不会重新执行计算函数。两者经常配合使用父组件用useMemo缓存引用型props子组件用React.memo拦截无必要的重渲染。比如封装一个表格操作列组件每行的操作按钮都是一组固定的JSX配置父组件通过useMemo缓存配置对象子组件用memo避免每次渲染都重建按钮这种组合拳在实际项目里改善交互流畅度的效果非常明显。另外提醒一点在React Compiler没有普及到所有项目之前这种手工优化仍然是React应用性能调优的基本功。React官方正在推进编译器自动记忆化但即便未来自动化覆盖大部分场景理解useMemo/React.memo的协作逻辑对解读编译器生成的代码也很有帮助。4.4 useMemo与useEffect各自的计算时机这两个Hook名字相似职责却大相径庭。useMemo是同步的计算在渲染过程中发生计算的结果会直接参与本次渲染。useEffect是渲染后的副作用在浏览器完成绘制之后才执行通常用于发起请求、订阅事件、操纵DOM等。最直观的差异在于能否立即使用结果。渲染阶段useMemo的结果可以直接写在JSX里useEffect里算出来的结果则必须经历一次“setState → 重新渲染”的循环才能显示。这也是为什么我建议能派生就派生能用useMemo计算的不要让数据绕弯走useEffect再回渲染。有个反面案例很能说明问题有次我为了让一个列表数据在某个state变化时更新用了useEffect去setState结果显示页面闪了一下旧数据再跳到新数据就是因为多绕了一次渲染。改成useMemo依赖那个state之后渲染一次就拿到了正确数据干净利落。5. useMemo误用与性能优化的常见坑位5.1 滥用useMemo反而更慢的实证网上有些说法极端了说“不用useMemo的React开发者不是好开发者”。实际情况恰恰相反滥用useMemo带来的问题不光是代码可读性的问题在某些场景下甚至会让组件变得更慢。原因在于useMemo本身不是免费的。每次渲染都要进入useMemo的内部逻辑依次执行依赖数组的遍历和Object.is比较同时缓存表本身也会占用内存。如果计算函数本身特别轻量——比如只是加减乘除、拼接字符串——那么“省下计算的耗时”甚至比“比对依赖的耗时”还要少净收益是负数。我见过一个同事把简单的数组长度计算都包了useMemoconst arrLength useMemo(() arr.length, [arr]);这种属于典型性能洁癖。useMemo的正确打开方式是面向“重计算”而不是面向“所有变量”。判断标准可以直接在浏览器里用Performance面板录制对比推迟优化比过早优化要务实得多。5.2 依赖项写错导致数据不更新这是我在评论区里被问得最多的一个问题“为什么useMemo的值不更新”大部分情况都是依赖数组的问题。可能漏了依赖导致缓存一直停留在旧值也可能依赖了过多无关项导致缓存频繁失效计算函数每次渲染都被执行白白消耗性能。排查建议是使用ESLint插件react-hooks/exhaustive-deps把依赖检查把进代码规范里。它会在编译期提示你哪些依赖漏了哪些依赖不需要直接消灭一整个类目的bug。我一开始觉得这个插件有点烦人动不动就提示但对抗依赖数组写得随意的问题它其实是最可靠的防线。还有一类的依赖问题特别隐蔽——依赖项本身每次渲染都在变化。比如父组件传入了一个箭头函数这个函数如果没有useCallback包裹引用每次都会变传递到useMemo的依赖数组里去就会导致依赖永远在变useMemo形同虚设。这个问题经常藏在多层组件传参之后肉眼很难察觉用React DevTools的Profiler可以很快定位频繁重计算的组件。5.3 缓存机制带来的“隐藏内存”与过期数据风险长时间运行的单页应用里如果useMemo缓存了体积很大的数据对象而依赖迟迟不改这份数据就会一直驻留在内存中。极端情况下比如用户切换了账号旧账号的数据还挂在某个组件的缓存里没有释放虽然组件已经不再访问它但它仍然占用内存。实践中我给两条建议第一能计算后再丢弃的临时大数据不要放进useMemo比如一次性展示的汇总表如果不跨渲染复用真没必要缓存第二组件被卸载时useMemo的缓存会随组件实例销毁一并释放所以担心内存泄漏的话更多要关注的是全局性的状态管理而不是局部useMemo。比如如果一个组件在隐藏后仍然被挂载CSS display:none那么useMemo缓存不会释放这是正常的你需要判断这个组件是否需要继续维持缓存。另一个“过期数据”的场景更隐晦当你用useMemo缓存了某个计算结果同时在useEffect里又对这个结果做了进一步的监听。如果useMemo的依赖没关联到正确的源头很容易出现“先显示一条从旧缓存派生出来的数据再悄然变成新数据”造成视觉上的一闪。解决思路跟上文说的闭包陷阱相同回到依赖数组认真核对。5.4 React Compiler与未来优化趋势写这篇文章前我也专门调研了React Compiler的现状。React团队一直在推进自动记忆化让编译器在构建期识别组件内哪些计算可以被缓存、自动包上记忆逻辑到时候很多原来需要手工写useMemo/useCallback的地方会减少不少。但目前React Compiler还没有覆盖到所有生产项目的方方面面而且它自动生成记忆逻辑也意味着你对代码的控制力会被削弱。所以现阶段我给团队的建议很保守React Compiler特性的学习理论没问题但业务代码里应该先把手写的useMemo/useCallback规范起来。这不只是在优化运行性能更是在帮助自己和同事建立对渲染时机、引用稳定性的认知模型这个认知对排查各种奇奇怪怪的渲染bug非常有帮助。5.5 一套实用的优化套路从怀疑到验证最后给出一套我自己的排查优化流程写完useMemo以后可以从这三个角度自检第一步先证明有性能问题再优化。打开DevTools的Performance录制观察组件渲染耗时确认瓶颈确实在大计算或频繁重渲染。别用预感代替实测。第二步检查依赖是否最小。打开React DevTools的Profiler查看是哪一次渲染触发了useMemo重算这次渲染的依赖来源是什么尝试把依赖缩小到最基础的基本类型值。第三步验证优化是否有效。优化完再录制一次Performance对比一段时间里的JS执行耗时与FPS。如果优化前后差距不明显果断撤掉useMemo保持代码简单。这套流程适合单点优化。如果是全局性的渲染性能问题比如整个应用频繁卡顿那应该先从状态管理架构和组件拆分层面找原因useMemo无法解决所有性能问题。6. 写在最后的实际操作体会如果让我用一句话总结useMemo那就是给组件一个“值得吃的对象”和“不值得吃的工作之间的记账本”。它帮你把昂贵的计算推迟到真正需要时执行把稳定的引用传递给下游组件但前提是依赖数组写得精准、使用边界划得清楚。我个人在实际项目中踩过不少坑最深刻的体会是useMemo不是银弹但确实是React应用性能优化工具箱里缺一不可的扳手。别迷信它也别忘了它找准它的使用场景你的React代码质量和运行效率都会上一个大台阶。最后再补充一个小技巧把useMemo和React.memo按组件边界组合使用而不是在每个变量周围乱包一气这样既能保持代码清爽又能真正看到性能优化带来的收益。