why-did-you-render 深度解析: monkey patch 如何追踪可避免的重渲染

why-did-you-render 深度解析: monkey patch 如何追踪可避免的重渲染【免费下载链接】why-did-you-renderwhy-did-you-render by Welldone Software monkey patches React to notify you about potentially avoidable re-renders. (Works with React Native as well.)项目地址: https://gitcode.com/gh_mirrors/wh/why-did-you-renderwhy-did-you-render 用 monkey patch 包住 React 的createElement、hooks 与 JSX 入口把「本可避免的重渲染」变成可定位的 diff 报告。全文拆解它的追踪判定、四种组件补丁、diff 算法、owner 归因与 React 19 接管路径读后可接入项目并看懂每条日志。它回答的是「为什么又渲染」不是「渲染有多慢」React 的重渲染成本在组件粒度上父组件一次重渲染会让所有未优化的子组件跟着重渲染。React.memo只能告诉你「这次跳过了」却回答不了反面问题——当重渲染真的发生时是 props 的引用变了而值没变还是某个 hook 的结果变了甚至是父组件自己多渲染了一遍手动在组件里console.log对比 props只能覆盖一层、还要自己写深比较。why-did-you-render下称 WDYR取代的就是这类手工排查。它的设计边界很明确这是一个观测工具补丁只读快照、计算 diff、调用notifier不拦截也不改变渲染结果异常时回退到原始createElement保证不吞错tests/index.test.js 里有「dont swallow errors」用例。它是开发期工具README 明确禁止用于生产环境理由是显著拖慢 React 且 monkey patch 可能引入意外行为。它只报告可避免的重渲染默认静默掉那些 props/state 值真的变了的重渲染把噪音留给可选的logOnDifferentValues。理解了这三条边界再看它的实现就是一条主线用最小侵入的包装在每次渲染时拿到「上次与这次」的输入做一次确定性的 diff把差异归因到具体字段。状态放在哪里一张全局 store一枚组件静态标记全部运行状态集中在模块单例 wdyrStore.js字段类型用途React/optionsobject被 patch 的 React 实例经 normalizeOptions.js 补全默认值后的用户配置origCreateElement/origCreateFactory/origCloneElementfunction原始 API 引用用于异常回退与还原componentsMapWeakMap原始组件 → 补丁后组件的缓存同一组件只包一次ownerDataMapWeakMapowner 的 fiber →{props, state, hooksInfo, ...}快照是 owner 归因的数据源hooksInfoForCurrentRenderWeakMap当前这次渲染中 owner 的 hooks 结果存档后即清除ownerBeforeElementCreationfiber创建子元素前一刻记录的 owner子组件补丁读取它作为nextOwner三个 map 全部用WeakMap组件与 fiber 被 GC 时 store 不持有强引用patch 不产生额外生命周期管理成本。全局配置之外每个组件还可以挂一枚静态标记types.d.ts 中定义为boolean或WhyDidYouRenderOptionsEnhancedMenu.whyDidYouRender true; // 或 false EnhancedMenu.whyDidYouRender { logOnDifferentValues: true, // 值真的变了也报告 customName: Menu, // 覆盖日志里的显示名 };全局选项的默认值由normalizeOptions固定src/normalizeOptions.js关键几项选项默认值作用include/excludenull按displayName匹配的正则列表exclude优先级最高trackAllPureComponentsfalse批量追踪React.PureComponent与React.memo组件trackHookstrue是否包装并追踪原生 hookstrackExtraHooks[][[模块, hook名], ...]追踪自定义 hook如 react-redux 的useSelectorlogOwnerReasonstrue额外报告「owner 为什么重渲染」logOnDifferentValuesfalse默认只报告「值相等」的重渲染true则报告所有重渲染hotReloadBufferMs500HMR 完成后忽略通知的缓冲毫秒数notifierdefaultNotifierupdateInfo的最终消费者可整体替换titleColor/diffNameColor/diffPathColor/textBackgroundColor#058/blue/red/white控制台配色hotReloadBufferMs: 500是实打实的实现参数而非文案defaultNotifier.js 里createDefaultNotifier向 webpack 的module.hot.addStatusHandler注册回调当 HMR 状态回到idle时置inHotReload truesetTimeout(hotReloadBufferMs)后再放开——热更新触发的整树重渲染因此不会刷屏。一个组件凭什么进入追踪入口是getWDYRTypesrc/whyDidYouRender.js先过一道「支持性」闸门getIsSupportedComponentType——memo递归解开.type、forwardRef解开.render、函数组件直接通过不满足的组件直接返回nullcreateElement原样透传零开销。支持性通过后进入shouldTracksrc/shouldTrack.js判定顺序本身就是优先级表优先级判断结果1exclude任一正则命中displayName不追踪压过include和手动标记2Component.whyDidYouRender false不追踪3仅 hook 变化路径whyDidYouRender.trackHooks false不追踪 hook 变化4Component.whyDidYouRender为真值追踪5trackAllPureComponents且组件是PureComponent或memo追踪6include任一正则命中追踪兜底以上都不满足不追踪这里的「为什么」值得注意exclude放最前面是因为它是团队级开关比如把第三方 HOC 全部排除必须能压过一切个体配置whyDidYouRender false次之让trackAllPureComponents开后仍能按组件豁免。displayName由 getDisplayName.js 按displayName → name → memo 内层 type → forwardRef 的 render → 字符串本身 → Unknown的链式回退取得正则匹配、日志标题、include/exclude都用它所以自定义的customName也会进入这套匹配。通过判定的组件经createPatchedComponent包装后写进componentsMapWeakMap同一组件后续每次createElement都复用同一个补丁副本包装成本只付一次。四种组件四套补丁同一个快照套路createPatchedComponent按类型分派到 patches/ 下四个补丁器组件形态补丁器快照存放处关键细节类组件patchClassComponent.js实例this._WDYRrenderNumber、prevProps/prevState/prevOwner子类化原组件StrictMode 下跳过奇数序渲染处理render被bind的边角函数 / 字符串标签patchFunctionalOrStrComponent.js包装函数内两个useRefprevProps、prevOwner字符串标签如div先转成包装函数再包isPure标志决定「空 diff」报告规则React.memopatchMemoComponent.js递归内层解开 memo → 按内层类型递归补丁 → 用原始compare函数重新React.memo包回React.forwardRefpatchForwardRefComponent.js递归内层内层若是 memo 则先以原compare重包再进forwardRef注意 memo 与 forwardRef 补丁都刻意保留原compare追踪不应改变组件的渲染决策跳过/重渲染的行为必须与未包装时一致。函数补丁的核心循环节选自 patchFunctionalOrStrComponent.jsfunction WDYRFunctionalComponent(nextProps, refMaybe, ...args) { const prevProps prevPropsRef.current; prevPropsRef.current nextProps; const prevOwner prevOwnerRef.current; const nextOwner wdyrStore.ownerBeforeElementCreation; prevOwnerRef.current nextOwner; if (prevProps) { const updateInfo getUpdateInfo({ prevProps, nextProps, prevOwner, nextOwner, /* ... */ }); const notifiedByHooks (!updateInfo.reason.propsDifferences || (isPure updateInfo.reason.propsDifferences.length 0)); if (!notifiedByHooks) wdyrStore.options.notifier(updateInfo); } return FunctionalComponent(nextProps, refMaybe, ...args); }这里的门控规则对应findObjectsDifferences的两种返回props引用未变时返回false父组件重渲染但子 props 是同一对象子跟着重渲染属正常不报告props引用变了时返回差异数组其中空数组表示「对象换了、内部值全是同一引用」。函数组件在引用变化时一律报告含空数组唯独纯组件memo的空数组静默——那种情形只能由自定义compare允许重渲染造成属于设计内行为。类补丁没有这层门控除首次外每次渲染都调用notifier是否打印完全交给通知层。StrictMode 的细节在类补丁里它沿 fiber 链检查REACT_STRICT_MODE位标记0b1000拷贝自 React 内部常量见 consts.js 与 utils.js命中后跳过renderNumber为奇数的渲染——StrictMode 下渲染成对出现报告偶数序即可。所有补丁都会把原始组件函数挂到包装组件的ComponentForHooksTracking上。这是 hook 追踪的关键hooks 在包装组件里执行getCurrentOwner()拿到的是包装组件的 fiber但日志必须显示原始组件名、按原始组件判定是否追踪ComponentForHooksTracking就是这层指针。React 19 之后钩子不能再只挂在 createElement 上React 16 的 automatic JSX 转换下开发模式的 JSX 编译产物是jsxDEV(...)调用来自react/jsx-dev-runtime并不经过React.createElement。只 patchcreateElement的工具在 React 19 的开发模式下会彻底失明。WDYR 的对策是让 Babel 把【免费下载链接】why-did-you-renderwhy-did-you-render by Welldone Software monkey patches React to notify you about potentially avoidable re-renders. (Works with React Native as well.)项目地址: https://gitcode.com/gh_mirrors/wh/why-did-you-render创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考