全部专栏

Fiber架构

Hooks原理

渲染流程

diff算法

调度与并发

性能调整

事件程序

高级特性

实验为了弥补原理和实践的鸿沟。可以参与实验，也可在线体验

React.memo 与 useMemo / useCallback 的配合

直觉锚定

想象一个公司的审批流程。每个部门提交报告给总经理审批。如果某个部门的报告内容没有任何变化聪明的做法是直接跳过这个部门，不用重新审批。

但这里有个陷阱：即使报告内容没变。如果换了新的封面总经理还是会认为"这是一份新报告"，重新审批一遍。

• 部门 = 子组件
• 报告 = props
• 审批 = 重新渲染
• 跳过审批 = React.memo 的 bailout 你可能在一次项目中因为忘记 memo 而导致子组件频繁渲染，却不明白为什么。
• 换了封面但内容没变= 传了新的对象/函数引用（如 {color:'red'}。 =>...) 从常见痛点来看，props 看起来没改，但实际被 new 对象/函数替换导致 memo 无效。
• memo + useMemo/useCallback = 既保证内容不变，又保证引用不变。方法的观点是，使用 useMemo/useCallback 包裹产生新对象/函数的表达式。其实，

问题背景

你可能在一次性能调试中发现。即使父组件状态更新，子组件也无谓地重新渲染。那是因为默认情况下父组件每次重渲染都会导致所有子组件都重渲染——这正是我们要解决的问题。

function Parent {
const = useState;return (

 setCount}>{count}
    // props 完全没变，但每次 count 变都重渲染

);}

When count changes → Parent re-renders → ExpensiveList also re-renders,even though its items prop hasn't changed. This wasteful re-rendering is what React.memo addresses.

常见先入为主的误解：

• `React.memo` 和 `useMemo` 是同一个东西不同用法？错，它们 memoize 的目标完全不同：

• `React.memo`: memoize component
• `useMemo`: memoize value
• `useCallback`: memoize function

主要数据结构 — React.memo 的内部表示：

// react@packages/react/src/memo.js
export function memo {
return {
$$typeof: REACT_MEMO_TYPE。type,compare: compare === undefined?null : compare
};}

The returned object is a description whose type points back to original function and holds an optional comparison function.

bailout 的判断方法：

// FiberNode structure relevant for memo components
FiberNode {
pendingProps: object // new props
memoizedProps: object // previous props
type这方面，REACT_MEMO_TYPE
}

The algorithm checks if any update or context change has occurred before comparing props.

运行流程 — React.memo bail‑out 判断：

// Simplified updateMemoComponent from ReactFiberBeginWork.js
function updateMemoComponent {
// Step 1 – check updates or context changes
if {
// Must process updates – cannot bail out
} else {
// Step 2 – compare props via shallowEqual or custom fn
var prevProps = workInProgress.memoizedProps;var compare = workInProgress.type.compare;var shouldUpdate;if { // custom comparison fn present?shouldUpdate = compare;} else { // default shallow comparison
shouldUpdate =!shallowEqual;}
if { // props unchanged -> bail out!return bailoutOnAlreadyFinishedWork;}
}
// Props changed -> normal rendering path
return updateFunctionComponent;}

ShallowEqual itself:

// packages/shared/shallowEqual.js
function shallowEqual{
if) return true;按理说，if return false;const keysA=Object.keys,keysB=Object.keys;说起来，ifreturn false;for{
if)return false;}
return true;}

Pain point

If you frequently create new objects or functions as props without stabilizing m,your component will never hit bail‑out path even though visually nothing changed—an invisible performance drain that shows up only under heavy load.

浅比较被"骗"的场景：

// Example where MemoChild fails because every prop is a new reference:
const MemoChild = React.memo{
return 

{items.length}
});function Parent{
const =useState;按理说，return (
console.log} // new function each render
style={{color:'red'}} // new object each render
items={} // new array each render
/>
);}

Each render produces fresh references so shallowEqual always fails → no bailout → whole subtree re‑renders unnecessarily.

useMemo / useCallback 修复引用稳定性：

// Stabilizing references with hooks:
function Parent{
const =useState;const handleClick = useCallback=>{
console.log;},)，// keeps same ref unless count changes
const style = useMemo=>,);// never changes
const items = useMemo=>,);// stable array
return (

);}

Now MemoChild’s shallowCompare passes → bailout occurs → entire subtree skipped unless actual prop values truly change.

设计动机与权衡 — 为什么默认浅比较而不是深比较？：

• Avoid high cost of deep comparisons:  Your list may contain nested objects that would be expensive to traverse every render.
\
• Avoid ambiguity:  A deep comparison can’t distinguish 娱乐ween “need reference stability” vs “content change”. Deeply equal objects could still trigger re‑renders due to or reasons such as event handlers.
\
• Simplicity:  Slightly more predictable API—developers explicitly decide which references matter by using {/* …*/}.

成本分析 — 使用 useMemo/useCallback 是否值得？ ： \ \ \ \ \ \ \ \ \ \ \ \ \t\t\t \t\t\t \t\t\t \t\t\t " **Key takeaways**

Comparison per Render Cycle*
No Memo just plain refs	Memos + Refs with stable deps	Total Work	Total Overhead		If no actual rerender avoided?按理说，
No Memo new refs each time	Memos + Refs stable
…不过，	…	…	…	…

Scenario	What happens?	When do memos help?说起来，
Heavy child component	Bypass whole subtree when parent state changes but child sees same data	✅ If child is expensive
Light child component	Memos cost more than benefit	❌ Avoid unless needed
Function passed down	Reference stability matters for downstream effects/equality checks	✅ If used in dependences

Use this table when deciding wher to wrap a component in `` and stabilize its props with `/`.

Context 性能问题与调整： Pain point: You may have a global context that updates frequently . Every consumer gets scheduled for re‑render even those that don’t read changing value—this can become a bottleneck in large trees.

* The root cause is that context propagation marks every consumer node before any bailout logic runs.* ### Why Context Bypasses Bailout When a Provider’s value changes: * `propagateContextChange` walks entire subtree. * It marks **every** fiber that consumes *any* field of that context as needing an update. * During subsequent `beginWork`。even if `React.memo` would normally skip based on unchanged props ** presence of marked context forces rerender**. 再看Thus，Parent renders → Provider value changes → Propagation marks UserProfile & ExpensiveTree → Even though ir own props are unchanged,y still get rendered again. ### Optimizing Context Updates #### Split Contexts into Smaller Pieces jsx const ThemeContext = createContext;const UserContext = createContext;const LocaleContext = createContext;function App { const = useState;怎么说呢，const = useState;return ( {/* Only subscribers interested in specific pieces get updated */} {/* No consumer here – stays untouched */} );} #### Use Memoized Provider Value jsx // Only rebuild object when actual fields change: const value = useMemo =>,);，​{/* consumers see unchanged reference */};#### Children Pattern Avoids Re‑rendering Intermediate Nodes jsx function Layout { const me = /* consumes ThemeContext */ /* But children prop remains same reference */ null;return，} // Now ExpensiveTree inside Layout will not rerender on me change. // Because Layout's own children element didn't change reference. #### Selector-Based Context If you need fine-grained selection without splitting contexts: jsx // Using Zustand or Jotai selectors: import {createStore} from 'zustand';const store=createStore);const me=getStore;// Only this selector will cause subscriber rerender when me updates. ### Pain Point Summary * **You might think “context works like Redux”,but it doesn’t support selectors natively**—all consumers are notified. * **Splitting contexts may seem verbose**。but it dramatically reduces unnecessary renders across large trees. * **Using a single Provider with many unrelated values leads to wasted CPU cycles**—you’re paying for every consumer’s lifecycle traversal even when y don't care about changed field.

为什么列表必须加 key： Pain point: If you forget keys or misuse index-based keys in dynamic lists you’ll see unexpected UI glitches and massive wasted renders—especially under rapid inserts/deletes. ### Core Diff Algorithm Recap with Keys The reconciliation algorithm uses keys as identity tokens: 1️⃣ Build a map from key→fiber of old list. 2️⃣ Walk new list: a) If key exists → reuse fiber. b) Else → create new fiber. c) After reuse/move decisions -> insertBefore only DOM movement. When key is omitted this map collapses into an index-by-index match which ignores logical identity. Any insertion at head causes *every subsequent item*’s identity to shift ⇒ all fibers are treated as moved/changed ⇒ entire subtrees are destroyed/recreated. Resulting costs: | Operation | Cost | |-----------|-------| | Fiber creation/destruction | High | Prop diffing & state resets | High | DOM API calls | High With correct keys se costly operations drop drastically because most fibers survive unmodified and only minimal DOM moves occur. ### Common Misunderstanding Captured by Pain Point: • “Index keys are fine as long as I don’t reorder items.” • “Keys just help diffing – y don’t affect state.” Both statements hold true only when list order is immutable after initial mount. In real-world apps lists usually reorder/filter/sort—index keys break both correctness and performance. ### Practical Tips: • Use unique IDs from backend whenever possible. • For static lists where ordering never changes just before mounting consider using index safely—but document this assumption clearly so future maintainers don’t introduce bugs later. and keep this simple rule handy while debugging flickers after filtering/sorting events."

This section covers how React.lazy + Suspense achieve code‑splitting through throwing Promises during rendering—a seemingly counter‑intuitive technique but highly effective.

This part explains *** overusing ``/`` can actually hurt performance—ir overhead outweighs benefits unless justified by real cost savings.

---

考核题目

---

从问题一来看，两种导致 React.memo 拦不住渲染的原因，并说明为什么。说起来，

• 原因一父组件传递的是 新创建的对象或函数引用。- 为什么拦不住虽然对象或函数本身属性相同。浅比较检测到引用变化，故视为props已更改，触发完整子树重新渲染。

• 原因二子组件内部使用了 或者使用了 setState 等引起副作用，而且该副作用依赖于外部值。- 为什么拦不住即使props未变，只要存在对上下文或副作用依赖的变化。React 在更新时会标记该子树为需要更新，绕过memo 的 bail-out 检查，从而强制重新渲染。

---

问题二这方面，给定三个只使用部分字段的 Consumer；按理说，avatar 改变后哪些会重渲染？

• Header不会重渲染。因为它只读取 name 字段，而 avatar 改动不会触发其订阅。
• Profile不会重渲染；仅受 age 字段影响，
• Avatar会重渲染，因为它正好消费被修改的字段。

如果想进一步调整。可以拆分成三个独立的 Context 或者使用自定义 Hook 做选择器，只订阅自己关心的数据字段，从而避免无谓更新。

---

再看问题三，《HeavyList》包在 React.memo 中；是否真正受益于 handleSelect 使用 useCallback？

• 当你把 handler 用 useCallback => {...},) 包装后它始终保持同一引用。由于 HeavyList 被包裹在 内，只有当传入 prop 引用改变时才会重新渲染。此处 handler 永远保持不变，所以 HeavyList 不会因点击事件变化而多次重新挂载——这是一个真实可观测到的小幅提高。

如果去掉 useCallback 并改为直接写箭头函数：

jsx const handleSelect==>{ console.log;}，

则每一次父级 Rerender 时都会创建一个新的匿名函数。对应的新引用将触发 HeavyList 的 完整挂载——虽然视觉上没有差异，但它会执行整个虚拟列表计算和 Diff，消耗 CPU 时间与内存。

---