在 React 开发中，useMemo 是优化性能的利器，但许多开发者都曾遇到过这样的困惑：当父组件重新渲染时，子组件内的 useMemo 值似乎被“保留”了下来；而一旦给组件更换 key，useMemo 却被重新计算。这种看似矛盾的行为背后，隐藏着 React 对组件身份与缓存生命周期的深刻设计。本文将带你一探究竟。
现象：两种场景下的不同表现
假设我们有一个父组件，它内部渲染一个子组件，子组件中使用了 useMemo 来计算一个昂贵的值。当父组件因状态更新而重新渲染时，子组件虽然也会被重新执行，但 useMemo 的依赖如果没有变化，其返回的结果依然是缓存中的旧值。这符合预期，也是 useMemo 存在的意义。
然而，一旦我们给子组件添加一个 key 属性，并在父组件渲染时改变这个 key（例如从 1 改为 2），情况就不同了：useMemo 被重新计算，仿佛之前的缓存完全失效。同样是父组件引起的重新渲染，为什么 useMemo 的行为截然不同？
核心原因：组件实例的身份决定缓存生命周期
要理解这个差异，需要从 React 的组件实例化与卸载机制说起。当父组件渲染时，React 会对子组件进行 协调（reconciliation）。协调的核心是比较新的虚拟 DOM 树与旧的虚拟 DOM 树，决定哪些节点需要更新、复用或卸载。
无 key 时的复用逻辑
如果子组件没有显式指定 key，React 会默认使用其在兄弟节点中的索引作为隐式 key。当组件仅是重新渲染（未改变类型或位置），React 会认为它是同一个组件实例，因此复用该实例。这意味着组件的状态、ref、以及 useMemo 等 hook 中存储的缓存数据都会被保留。此时，即使父组件重新渲染，子组件内部的 useMemo 也不会重新计算，除非其依赖数组中的值发生变化。
这就是为什么表面上看起来“useMemo 被保留了”——实际上，是整个组件实例未销毁，所有 hook 状态自然延续。
key 变更触发的销毁与重建
当我们给组件加上 key，并为它赋予不同的值时，React 就获得了一个精确的标识符。协调过程中，如果发现相同位置上出现了不同的 key，React 会认为旧的组件实例已不再需要，于是执行卸载操作，并将新组件挂载到该位置。
卸载意味着组件实例的一切都会被清除，包括所有的 hook 状态和缓存。新的组件实例重新挂载时，useMemo 会从头开始计算（因为初始状态下没有缓存值）。这就是为什么 key 改变后，useMemo 看上去被“重新创建”了。
深入理解：React 的 “组件身份” 哲学
这种行为实际上体现了 React 的一个核心设计原则：组件的身份由其类型和 key 共同决定。当身份不变时，React 倾向于复用实例以保持状态连续性；当身份变化时，React 果断地摧毁旧实例，创建新实例以确保组件从干净状态启动。
useMemo 的缓存是与组件实例绑定的。组件实例未被销毁，缓存就有效；实例一旦销毁，缓存也随之消失。这并非 useMemo 的特殊行为，而是所有 hook（包括 useState、useCallback 等）共享的规则。你可以观察到，key 改变后，组件的局部状态也会重置，这进一步印证了上述原理。
实践启示：如何正确使用 key 与 useMemo
-
使用 key 管理组件状态的生命周期：当你希望强制重置某个组件的所有内部状态（包括
useMemo缓存）时，改变其key是最简单直接的方式。例如，表单组件在提交后需要清空所有输入和计算结果，只需更新key即可。 -
避免滥用 key 导致性能下降：不当的
key变更会使组件频繁销毁重建，反而抵消了useMemo的优化效果。在列表渲染中，确保key稳定且唯一，不要让每个子组件每次渲染都获得不同的key。 -
理解依赖数组的重要性：
useMemo的依赖数组决定了何时重新计算。即使组件实例被复用，若依赖值变化，缓存也会失效。因此，合理设置依赖项比单纯依赖key更重要。
结语
React 对 useMemo 缓存的不同处理方式，本质上是组件实例生命周期管理的自然结果。key 作为组件身份的标识符，直接控制了是否创建新实例；而 useMemo 只是依附于实例的“副产品”。理解这一层设计，不仅能解答开发中的疑惑，更能帮助我们更精准地运用 key 来管理组件行为，写出更健壮的 React 应用。
在性能优化的道路上，没有银弹。只有深入框架的运作机制，才能让你的每一个 useMemo 都用在刀刃上。