1. 项目概述React 中的派生状态到底在解决什么问题“Using Derived State in React”这个标题看起来平平无奇但背后藏着 React 开发者踩过最多坑、面试被问得最频繁、文档里写得最含糊的一类设计难题。我带过十几支前端团队每年做技术复盘时“状态同步失控”稳居 Bug Top 3——不是接口报错不是样式错位而是用户明明改了表单字段提交时却还是旧值或者父组件传了个新 ID子组件内部的缓存数据没刷新列表渲染出错又或者一个搜索框输入后清空再点“重置”按钮输入框闪一下又恢复了上次内容……这些都不是 bug是派生状态管理失当引发的逻辑雪崩。派生状态Derived State指的不是直接由用户操作或 API 响应产生的原始状态而是基于其他状态props 或 state计算得出、且需要在组件生命周期中主动维护的一类中间态。它和useState初始化时的“初始值”有本质区别初始值只在挂载时求一次而派生状态必须在 props 变化、state 更新、甚至异步回调完成等多个时机被重新计算并同步。React 官方明确反对“在 render 里直接计算并使用”因为这会导致不可预测的重渲染、跳帧、甚至无限循环。所以才有了getDerivedStateFromProps这个静态方法也才有了后来 Hooks 时代useEffectuseRef的组合解法。你可能已经听过“避免派生状态”这句教条但现实很骨感表单联动如省市区三级联动选中省份后城市下拉需重置、受控组件与非受控组件混合如富文本编辑器初始化后允许用户手动修改、服务端渲染SSR后客户端状态对齐hydration 同步、以及所有需要“响应式缓存”的场景比如根据路由参数预加载并缓存某条详情数据都绕不开派生状态。它不是可选项而是 React 应用规模上到中大型后的必答题。本文不讲概念定义只讲我在真实电商后台、SaaS 管理系统、实时协作白板三个项目里如何用getDerivedStateFromProps稳住 Class 组件又如何用useEffectuseRefuseMemo的黄金三角在 Function 组件里把派生状态管得明明白白、测得清清楚楚、改得毫无压力。2. 派生状态的设计逻辑与方案选型为什么不能只靠 useEffect2.1 派生状态的本质矛盾谁该拥有状态主权先抛开代码回到一个最朴素的问题如果一个值 A 是由另一个值 B 计算得来那么 A 的“所有权”归谁是 B 的持有者父组件还是 A 的使用者当前组件这个问题的答案直接决定了你该用哪种方案。场景一A 是 B 的纯函数映射且无副作用比如const displayName firstName lastName。这种情况下A 完全由 B 决定当前组件不该自己维护displayName这个 staterender 里直接算就行。这是最理想的状态也是 React 推崇的“单一数据源”。场景二A 需要独立于 B 的更新周期存在且有自身生命周期比如一个搜索输入框父组件传入initialQuery组件内部需要维护currentQuery用户正在输入的值和cachedResults上次搜索结果。当initialQuery变化时currentQuery应该重置为空但cachedResults不该立刻清空——用户可能正看着结果想点进去你一刷新就没了。这时cachedResults就是派生状态它依赖initialQuery触发更新但更新逻辑是否保留旧缓存、是否发起新请求必须由当前组件自己决策。这就是派生状态的核心矛盾它既不能脱离源头props独立存在又不能完全交由源头控制其生命周期。Class 组件时代React 提供了getDerivedStateFromProps来解决这个矛盾——它是一个静态方法在每次 render 前被调用接收nextProps和prevState返回一个对象来合并进state。它的设计哲学是“状态同步是组件自己的事React 只提供钩子不代劳逻辑。”而到了 Hooks 时代官方推荐用useEffect替代。但很多人没意识到useEffect和getDerivedStateFromProps解决的根本不是同一类问题。useEffect是副作用执行器它在 render 后异步执行无法阻断本次 render而getDerivedStateFromProps是 render 前的同步状态修正器它能确保本次 render 使用的是最新、最一致的状态。举个例子父组件传入userId: 123子组件需要根据它加载用户信息并设置userStatus: loading。如果用useEffect第一次 render 会先用userStatus: undefined渲染出空白页0.5 秒后useEffect才触发设置userStatus: loading页面闪一下而getDerivedStateFromProps在第一次 render 前就判断nextProps.userId ! prevState.userId直接返回{ userStatus: loading }首次渲染就是 loading 态体验更顺滑。所以方案选型的第一原则是看你的派生状态是否需要影响本次 render 的输出。需要就用getDerivedStateFromPropsClass或useMemouseRef模拟Function不需要useEffect足够。2.2 Class 组件方案getDerivedStateFromProps 的正确打开方式getDerivedStateFromProps自 React 16.3 引入本意是替代即将废弃的componentWillReceiveProps。但很多团队把它用成了“万能 props 监听器”导致性能灾难。它的正确用法我总结为三条铁律它必须是纯函数只能读取nextProps和prevState不能访问this不能调用setState不能有副作用如发请求、改 DOM。它的唯一产出就是一个 plain object用于 shallow merge 到state。它只应在“props 变化导致 state 必须重置”时使用典型场景就是上面说的表单重置。比如一个UserProfileForm组件接收user: { id, name, email }内部有formData { name, email }。当父组件切换用户user.id变了formData必须重置为新用户的值否则用户看到的还是旧数据。这时getDerivedStateFromProps就是唯一安全的选择static getDerivedStateFromProps(nextProps, prevState) { // 关键只对比决定重置的 key不是所有 props if (nextProps.user.id ! prevState.lastUserId) { return { formData: { name: nextProps.user.name, email: nextProps.user.email }, lastUserId: nextProps.user.id // 记录当前生效的 userId }; } // 无变化返回 null 表示不更新 state return null; }注意lastUserId这个字段——它不是业务数据而是专门用来做 diff 的“锚点”。没有它nextProps.user.id每次都会和prevState.formData对比永远不等造成无限更新。它不能替代 componentDidUpdategetDerivedStateFromProps只负责状态同步不负责副作用。比如重置表单后你想自动聚焦第一个输入框这事必须放在componentDidUpdate里做componentDidUpdate(prevProps, prevState) { // 只在表单重置后聚焦 if (prevProps.user.id ! this.props.user.id) { this.nameInput.focus(); } }违反这三条轻则性能下降重则状态错乱。我见过最离谱的案例是有人在getDerivedStateFromProps里直接调用fetch结果每次父组件 rerender哪怕只是传了个无关的布尔值都触发一次请求后端报警邮件刷屏。2.3 Function 组件方案useEffect 的局限性与 useRef 的破局之道Hooks 时代官方文档说“getDerivedStateFromProps很少需要useEffect能搞定大部分场景”。这话没错但前提是你的场景真的“大部分”。一旦涉及首次渲染一致性、服务端渲染 hydration、或需要精确控制更新时机useEffect就露怯了。useEffect的本质是“副作用队列”它在浏览器 paint 之后执行且是异步的。这意味着它无法阻止本次 render 使用过期的 state它无法在 SSR hydrate 时同步执行useEffect在客户端才运行它的依赖数组[deps]如果漏掉某个依赖就会产生 stale closure拿到旧值。这时候useRef就成了破局关键。useRef返回的对象在组件整个生命周期内保持不变其.current属性可以存储任何值且更新是同步的。我们可以用它来模拟getDerivedStateFromProps的“同步状态修正”能力。核心思路是用useRef缓存上一次的 props key如lastUserId在useEffect里对比如果变了就同步更新本地 state并更新 ref。但useEffect本身是异步的怎么做到“同步”答案是把状态更新逻辑拆出来用一个自定义 Hook 封装并在 render 函数里直接调用。我写的useDerivedStateHook 长这样function useDerivedState( deriveState, // (nextProps, prevState) nextState deps, // 用于判断是否需要重置的依赖数组通常是 [props.id] initialState // 初始 state ) { const [state, setState] useState(initialState); const lastDepsRef useRef(deps); // 在 render 时同步检查并更新 const derived useMemo(() { const isChanged !shallowEqual(lastDepsRef.current, deps); if (isChanged) { lastDepsRef.current deps; return deriveState(deps, state); } return null; }, [deps, state, deriveState]); // 如果 derived 有值同步更新 state useEffect(() { if (derived ! null) { setState(prev ({ ...prev, ...derived })); } }, [derived]); return [state, setState]; } // 使用示例 function UserProfileForm({ user }) { const [formData, setFormData] useDerivedState( (newUser, prevState) ({ name: newUser.name, email: newUser.email }), [user.id], // 只有 user.id 变了才重置 { name: , email: } ); return ( form input value{formData.name} onChange{e setFormData({...formData, name: e.target.value})} / input value{formData.email} onChange{e setFormData({...formData, email: e.target.value})} / /form ); }这里useMemo是关键它在 render 阶段执行能拿到最新的deps和state通过shallowEqual判断依赖是否变化如果变了就调用deriveState计算新状态并更新lastDepsRef。useEffect只负责把计算结果应用到state上。整个过程保证了首次渲染时如果user.id已存在formData就是正确的初始值后续user.id变化formData也会在下次 render 前同步更新。这个方案比纯useEffect更健壮也比强行用 Class 组件更符合现代 React 生态。但它也有代价代码量增加理解成本略高。所以我的建议是新项目一律用此方案老项目迁移时优先评估是否真需要“同步更新”如果只是普通数据流useEffectuseCallback足够。3. 核心实现细节与实操要点从代码到线上稳定的每一步3.1 getDerivedStateFromProps 的深度实践电商后台商品编辑器的真实案例我们曾为一个日均百万 PV 的电商后台开发商品编辑器。核心需求是支持多语言 SKU如中文名、英文名、日文名每个语言字段可独立编辑但“主图 URL”字段是全局共享的——改任何一个语言的主图其他语言的主图字段也要同步更新。同时当管理员从商品列表点击进入编辑页时需要根据 URL 参数?id123加载商品数据但如果用户手动修改 URL 切换商品页面不能刷新而是要局部更新。这个场景完美覆盖了派生状态的三大痛点跨字段联动、URL 驱动的状态同步、以及避免重复请求。我们用 Class 组件实现了稳定运行三年的方案核心代码如下class ProductEditor extends Component { constructor(props) { super(props); this.state { // 主状态所有语言字段 locales: { zh: { name: , description: , mainImage: }, en: { name: , description: , mainImage: }, ja: { name: , description: , mainImage: } }, // 派生状态锚点 currentProductId: null, isLoading: false, error: null }; } // 关键只在 productId 变化时重置整个表单 static getDerivedStateFromProps(nextProps, prevState) { // 1. 检查 productId 是否变化 if (nextProps.match.params.id ! prevState.currentProductId) { return { currentProductId: nextProps.match.params.id, locales: { zh: { name: , description: , mainImage: }, en: { name: , description: , mainImage: }, ja: { name: , description: , mainImage: } }, isLoading: true, error: null }; } // 2. 检查是否需要同步 mainImage 字段跨语言 const nextLocales nextProps.initialData?.locales || {}; const prevLocales prevState.locales; // 如果任一语言的 mainImage 发生变化且不是由我们自己触发的避免循环 if ( nextLocales.zh?.mainImage ! prevLocales.zh.mainImage || nextLocales.en?.mainImage ! prevLocales.en.mainImage || nextLocales.ja?.mainImage ! prevLocales.ja.mainImage ) { // 同步所有语言的 mainImage 为最新值取第一个非空的 const newMainImage nextLocales.zh?.mainImage || nextLocales.en?.mainImage || nextLocales.ja?.mainImage || ; return { locales: { zh: { ...prevLocales.zh, mainImage: newMainImage }, en: { ...prevLocales.en, mainImage: newMainImage }, ja: { ...prevLocales.ja, mainImage: newMainImage } } }; } return null; } componentDidMount() { this.loadProductData(); } componentDidUpdate(prevProps) { // 只在 productId 变化后加载数据 if (prevProps.match.params.id ! this.props.match.params.id) { this.loadProductData(); } } loadProductData async () { try { const data await api.getProduct(this.props.match.params.id); // 注意这里不直接 setState而是让 getDerivedStateFromProps 处理 // 因为 data.locales 可能包含部分字段我们需要 merge 而非 replace this.setState({ isLoading: false, error: null }); } catch (err) { this.setState({ isLoading: false, error: err.message }); } }; handleLocaleChange (lang, field, value) { this.setState(prev { const newLocales { ...prev.locales }; newLocales[lang] { ...newLocales[lang], [field]: value }; // 如果改的是 mainImage触发跨语言同步 if (field mainImage) { const newMainImage value; newLocales.zh { ...newLocales.zh, mainImage: newMainImage }; newLocales.en { ...newLocales.en, mainImage: newMainImage }; newLocales.ja { ...newLocales.ja, mainImage: newMainImage }; } return { locales: newLocales }; }); }; render() { const { locales, isLoading, error } this.state; if (isLoading) return Loading /; if (error) return Error message{error} /; return ( div classNameproduct-editor LanguageTabs / div classNamelocale-fields input value{locales.zh.name} onChange{e this.handleLocaleChange(zh, name, e.target.value)} / input value{locales.zh.mainImage} onChange{e this.handleLocaleChange(zh, mainImage, e.target.value)} / {/* 其他语言字段... */} /div /div ); } }这个实现的关键细节双层派生逻辑第一层是productId变化时的全量重置清空表单设 loading第二层是mainImage变化时的跨语言同步。两者都通过getDerivedStateFromProps完成保证了 render 一致性。避免循环更新getDerivedStateFromProps里只对比mainImage字段不对比整个locales对象防止因handleLocaleChange导致的 state 更新再次触发getDerivedStateFromProps。数据加载与状态分离loadProductData只负责获取数据不负责设置localesgetDerivedStateFromProps负责将新数据 merge 进 state。这种职责分离让逻辑更清晰也便于测试。提示getDerivedStateFromProps的返回值必须是null或一个对象。返回{}空对象也会触发 state 更新导致不必要的 rerender。务必用return null表示“无需更新”。3.2 Function 组件方案useEffect useRef 的避坑指南在另一个 SaaS 管理系统中我们用 Function 组件重构了权限配置模块。需求是左侧树形菜单展示所有权限点右侧表单展示当前选中权限点的详细配置。当用户点击树节点时需要高亮当前节点加载该权限点的配置数据如果用户之前编辑过该权限点但未保存要提示“检测到未保存更改是否放弃”。这个场景下selectedNodeId是 props来自父组件的onSelectconfigData是派生状态需根据selectedNodeId加载而isDirty是否已修改是本地 state。三者关系复杂useEffect单独搞不定。我们最终采用的方案是useRef缓存selectedNodeIduseEffect负责加载数据useState管理configData和isDirty并通过useCallback确保事件处理器不会闭包旧值。function PermissionConfigPanel({ selectedNodeId, onNodeSelect }) { const [configData, setConfigData] useState(null); const [isDirty, setIsDirty] useState(false); const [isLoading, setIsLoading] useState(false); const [error, setError] useState(null); // 缓存上一次的 selectedNodeId用于对比 const lastSelectedIdRef useRef(selectedNodeId); // 每次 selectedNodeId 变化时重置 configData 和 isDirty useEffect(() { if (selectedNodeId ! lastSelectedIdRef.current) { // 重置状态 setConfigData(null); setIsDirty(false); setIsLoading(true); setError(null); // 更新 ref lastSelectedIdRef.current selectedNodeId; // 加载新数据 const loadData async () { try { const data await api.getPermissionConfig(selectedNodeId); setConfigData(data); setIsLoading(false); } catch (err) { setError(err.message); setIsLoading(false); } }; loadData(); } }, [selectedNodeId]); // 依赖 selectedNodeId // 处理表单变更 const handleConfigChange useCallback((key, value) { setConfigData(prev ({ ...prev, [key]: value })); setIsDirty(true); }, []); // 保存操作 const handleSave useCallback(async () { try { await api.updatePermissionConfig(selectedNodeId, configData); setIsDirty(false); } catch (err) { alert(保存失败${err.message}); } }, [selectedNodeId, configData]); // 离开前确认 useEffect(() { const handleBeforeUnload (e) { if (isDirty) { e.preventDefault(); e.returnValue 您有未保存的更改确定要离开吗; } }; window.addEventListener(beforeunload, handleBeforeUnload); return () window.removeEventListener(beforeunload, handleBeforeUnload); }, [isDirty]); if (isLoading) return Spinner /; if (error) return Alert typeerror message{error} /; if (!configData) return EmptyState /; return ( div classNameconfig-panel h2权限配置{configData.name}/h2 ConfigForm data{configData} onChange{handleConfigChange} / Button onClick{handleSave} disabled{!isDirty} {isDirty ? 保存更改 : 已保存} /Button /div ); }这个实现的避坑要点useRef 的时机lastSelectedIdRef.current必须在useEffect的同步部分更新不能等到异步的loadData里才更新否则在loadData执行期间如果selectedNodeId又变了ref 还是旧值导致逻辑错乱。useCallback 的必要性handleConfigChange和handleSave都依赖configData和selectedNodeId如果不加useCallback每次 render 都会生成新函数导致子组件如ConfigForm不必要的 rerender。更重要的是handleSave里的configData如果是 stale closure就会保存旧数据。副作用清理beforeunload事件监听器必须在组件卸载时移除否则会造成内存泄漏。useEffect的 cleanup 函数是唯一可靠的位置。注意useEffect的依赖数组[selectedNodeId]必须严格匹配实际使用的变量。漏掉selectedNodeIduseEffect就不会重新执行多写了configData就会在configData变化时也触发加载造成无限循环。3.3 测试驱动的派生状态验证如何写出真正可靠的单元测试派生状态逻辑一旦出错往往表现为“偶发性 UI 错乱”很难复现。所以测试必须覆盖所有状态转换路径。我们团队强制要求每个使用getDerivedStateFromProps或自定义派生 Hook 的组件必须有以下三类测试初始渲染测试验证组件挂载时state 是否为预期值。props 变化测试模拟nextProps变化验证getDerivedStateFromProps返回值是否正确。交互流程测试模拟用户操作如点击、输入验证状态流转是否符合业务逻辑。以ProductEditor为例Jest Enzyme 测试代码如下describe(ProductEditor, () { let wrapper; beforeEach(() { wrapper shallow(ProductEditor match{{ params: { id: 1 } }} /); }); it(should initialize with correct state on mount, () { expect(wrapper.state()).toEqual({ locales: { zh: { name: , description: , mainImage: }, en: { name: , description: , mainImage: }, ja: { name: , description: , mainImage: } }, currentProductId: 1, isLoading: false, error: null }); }); it(should reset state when productId changes, () { // 模拟 props 变化 wrapper.setProps({ match: { params: { id: 2 } } }); // 验证 getDerivedStateFromProps 的返回值需 mock 静态方法 jest.mock(./ProductEditor, () { const Original require.requireActual(./ProductEditor); return { ...Original, ProductEditor: class extends Original.ProductEditor { static getDerivedStateFromProps(nextProps, prevState) { // 我们只关心返回值不关心实际逻辑 return { currentProductId: nextProps.match.params.id, locales: { zh: { name: , description: , mainImage: }, en: { name: , description: , mainImage: }, ja: { name: , description: , mainImage: } }, isLoading: true, error: null }; } } }; }); // 重新渲染 wrapper shallow(ProductEditor match{{ params: { id: 2 } }} /); expect(wrapper.state().currentProductId).toBe(2); expect(wrapper.state().isLoading).toBe(true); }); it(should sync mainImage across locales when any one changes, () { const initialData { locales: { zh: { mainImage: url1 }, en: { mainImage: url2 }, ja: { mainImage: url3 } } }; wrapper.setProps({ initialData }); // 检查 getDerivedStateFromProps 是否返回了同步后的 locales // 此处需更深入的 mock略去细节 expect(wrapper.state().locales.zh.mainImage).toBe(url1); expect(wrapper.state().locales.en.mainImage).toBe(url1); expect(wrapper.state().locales.ja.mainImage).toBe(url1); }); });对于 Function 组件测试更简单因为useDerivedState是纯函数可以直接 import 并调用import { useDerivedState } from ./hooks/useDerivedState; test(useDerivedState should reset state when deps change, () { const deriveFn jest.fn((newDeps, prevState) ({ count: newDeps[0] })); // 第一次调用 const result1 useDerivedState(deriveFn, [1], { count: 0 }); expect(deriveFn).toHaveBeenCalledWith([1], { count: 0 }); expect(result1[0]).toEqual({ count: 1 }); // 第二次调用deps 变化 const result2 useDerivedState(deriveFn, [2], { count: 1 }); expect(deriveFn).toHaveBeenCalledWith([2], { count: 1 }); expect(result2[0]).toEqual({ count: 2 }); });实操心得不要试图测试useEffect的执行时机那属于 React 内部实现。只测试它导致的最终状态state、DOM 输出是否正确。用act()包裹异步操作确保测试环境与真实渲染一致。4. 常见问题与排查技巧实录那些年我们踩过的坑4.1 问题速查表高频故障现象与根因分析故障现象可能根因排查步骤解决方案组件首次渲染显示空白/默认值0.5秒后才显示正确数据useEffect替代getDerivedStateFromProps但未处理首次渲染一致性1. 检查useEffect依赖数组是否完整2. 在 render 函数里打印state值确认初始值是否正确改用useMemouseRef方案或在useState初始化时直接计算初始值父组件 rerender 导致子组件派生状态被意外重置getDerivedStateFromProps的 diff 逻辑错误对比了不该对比的 props1. 在getDerivedStateFromProps里添加console.log打印nextProps和prevState2. 检查返回值是否为null只对比决定重置的 key如id用shallowEqual工具函数做对象对比表单输入后切换 tab 再切回输入内容丢失useEffect里未正确处理cleanup导致状态被重置1. 检查useEffect的 cleanup 函数是否执行2. 检查useState的初始值是否依赖了 props将表单状态提升到父组件或用useRef缓存用户输入useEffect只负责同步到服务端useEffect无限循环A 更新导致 B 更新B 更新又触发 A 更新依赖数组漏掉变量或setState时未用函数式更新1. 在useEffect开头加console.log(effect run)2. 检查setState是否用了prev {...prev}形式使用 ESLint 插件eslint-plugin-react-hooks开启exhaustive-deps规则setState一律用函数式更新SSR 页面首屏闪烁FOUCuseEffect在客户端才执行服务端渲染的 HTML 与客户端不一致1. 查看页面源码确认服务端渲染的 HTML 是否包含正确内容2. 检查getServerSideProps或getStaticProps是否返回了足够数据服务端预取数据通过 props 传给组件或用getDerivedStateFromProps的 Class 组件方案4.2 独家调试技巧如何一眼定位派生状态问题Chrome DevTools 的 “Render When Props Change” 功能在 Components 面板右键组件 → “Highlight updates when props change”。当 props 变化时组件会高亮闪烁。如果高亮后 UI 没变说明getDerivedStateFromProps或useEffect没生效如果高亮后 UI 错乱说明状态同步逻辑有误。自定义 Hook 的调试代理为useDerivedState添加调试模式function useDerivedState(debugName, deriveState, deps, initialState) { const [state, setState] useState(initialState); const lastDepsRef useRef(deps); const derived useMemo(() { const isChanged !shallowEqual(lastDepsRef.current, deps); if (isChanged debugName) { console.group(%c[${debugName}] Deriving state, color: blue); console.log(next deps:, deps); console.log(prev deps:, lastDepsRef.current); console.log(prev state:, state); console.groupEnd(); } if (isChanged) { lastDepsRef.current deps; return deriveState(deps, state); } return null; }, [deps, state, deriveState, debugName]); useEffect(() { if (derived ! null debugName) { console.log(%c[${debugName}] Applying derived state, color: green, derived); } if (derived ! null) { setState(prev ({ ...prev, ...derived })); } }, [derived, debugName]); return [state, setState]; }调用时传入debugName: ProductEditor控制台就能清晰看到每次派生状态的触发条件和结果。React DevTools 的 “Highlight Updates” “Settings → Highlight updates when components render”开启后每次 render 都会高亮组件。如果一个组件频繁高亮但 props 没变大概率是useState的 setter 被多次调用或useMemo依赖项写错了。4.3 性能优化实战减少不必要的派生状态计算派生状态最大的性能风险是“过度派生”——把本该在 render 里直接计算的值硬塞进 state。比如// ❌ 错误过度派生 function ProductList({ products }) { const [filteredProducts, setFilteredProducts] useState([]); useEffect(() { setFilteredProducts(products.filter(p p.inStock)); }, [products]); return filteredProducts.map(p ProductItem key{p.id} product{p} /); } // ✅ 正确render 里直接计算 function ProductList({ products }) { const filteredProducts useMemo(() products.filter(p p.inStock), [products] ); return filteredProducts.map(p ProductItem key{p.id} product{p} /); }useMemo是纯计算不触发 rerender而useStateuseEffect会触发一次额外的 rerender。性能差距在列表项超过 100 时非常明显。另一个常见误区是“派生状态嵌套”。比如// ❌ 危险嵌套派生 function OrderSummary({ order }) { const [items, setItems] useState([]); const [total, setTotal] useState(0); useEffect(() { setItems(order.items); }, [order.items]); useEffect(() { setTotal(items.reduce((sum, item) sum item.price * item.qty, 0)); }, [items]); }这里items是order.items的派生total又是items的派生形成链式依赖。一旦order.items变化会触发两次useEffect两次 rerender。更优解是// ✅ 扁平化 function OrderSummary({ order }) { const { items, total } useMemo(() { const items order.items; const total items.reduce