React派生状态管理：从getDerivedStateFromProps到useEffect+useRef实战

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 时代useEffect+useRef的组合解法。

你可能已经听过“避免派生状态”这句教条，但现实很骨感：表单联动（如省市区三级联动，选中省份后城市下拉需重置）、受控组件与非受控组件混合（如富文本编辑器初始化后允许用户手动修改）、服务端渲染（SSR）后客户端状态对齐（hydration 同步）、以及所有需要“响应式缓存”的场景（比如根据路由参数预加载并缓存某条详情数据），都绕不开派生状态。它不是可选项，而是 React 应用规模上到中大型后的必答题。本文不讲概念定义，只讲我在真实电商后台、SaaS 管理系统、实时协作白板三个项目里，如何用getDerivedStateFromProps稳住 Class 组件，又如何用useEffect+useRef+useMemo的黄金三角，在 Function 组件里把派生状态管得明明白白、测得清清楚楚、改得毫无压力。

2. 派生状态的设计逻辑与方案选型：为什么不能只靠 useEffect？

2.1 派生状态的本质矛盾：谁该拥有状态主权？

先抛开代码，回到一个最朴素的问题：如果一个值 A 是由另一个值 B 计算得来，那么 A 的“所有权”归谁？是 B 的持有者（父组件），还是 A 的使用者（当前组件）？这个问题的答案，直接决定了你该用哪种方案。

• 场景一：A 是 B 的纯函数映射，且无副作用
  比如const displayName = firstName + ' ' + lastName。这种情况下，A 完全由 B 决定，当前组件不该自己维护displayName这个 state，render 里直接算就行。这是最理想的状态，也是 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 的输出。需要，就用getDerivedStateFromProps（Class）或useMemo+useRef模拟（Function）；不需要，useEffect足够。

2.2 Class 组件方案：getDerivedStateFromProps 的正确打开方式

getDerivedStateFromProps自 React 16.3 引入，本意是替代即将废弃的componentWillReceiveProps。但很多团队把它用成了“万能 props 监听器”，导致性能灾难。它的正确用法，我总结为三条铁律：

1. 它必须是纯函数：只能读取nextProps和prevState，不能访问this，不能调用setState，不能有副作用（如发请求、改 DOM）。它的唯一产出，就是一个 plain object，用于 shallow merge 到state。

2. 它只应在“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对比，永远不等，造成无限更新。

3. 它不能替代 componentDidUpdate：getDerivedStateFromProps只负责状态同步，不负责副作用。比如重置表单后，你想自动聚焦第一个输入框，这事必须放在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 生态。但它也有代价：代码量增加，理解成本略高。所以我的建议是：新项目一律用此方案；老项目迁移时，优先评估是否真需要“同步更新”，如果只是普通数据流，useEffect+useCallback足够。

3. 核心实现细节与实操要点：从代码到线上稳定的每一步

3.1 getDerivedStateFromProps 的深度实践：电商后台商品编辑器的真实案例

我们曾为一个日均百万 PV 的电商后台开发商品编辑器。核心需求是：支持多语言 SKU（如中文名、英文名、日文名），每个语言字段可独立编辑，但“主图 URL”字段是全局共享的——改任何一个语言的主图，其他语言的主图字段也要同步更新。同时，当管理员从商品列表点击进入编辑页时，需要根据 URL 参数?id=123加载商品数据；但如果用户手动修改 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 className="product-editor"> <LanguageTabs /> <div className="locale-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只负责获取数据，不负责设置locales；getDerivedStateFromProps负责将新数据 merge 进 state。这种职责分离让逻辑更清晰，也便于测试。

提示：getDerivedStateFromProps的返回值必须是null或一个对象。返回{}（空对象）也会触发 state 更新，导致不必要的 rerender。务必用return null表示“无需更新”。

3.2 Function 组件方案：useEffect + useRef 的避坑指南

在另一个 SaaS 管理系统中，我们用 Function 组件重构了权限配置模块。需求是：左侧树形菜单展示所有权限点，右侧表单展示当前选中权限点的详细配置。当用户点击树节点时，需要：

1. 高亮当前节点；
2. 加载该权限点的配置数据；
3. 如果用户之前编辑过该权限点但未保存，要提示“检测到未保存更改，是否放弃？”。

这个场景下，selectedNodeId是 props（来自父组件的onSelect），configData是派生状态（需根据selectedNodeId加载），而isDirty（是否已修改）是本地 state。三者关系复杂，useEffect单独搞不定。

我们最终采用的方案是：useRef缓存selectedNodeId，useEffect负责加载数据，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 type="error" message={error} />; if (!configData) return <EmptyState />; return ( <div className="config-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]必须严格匹配实际使用的变量。漏掉selectedNodeId，useEffect就不会重新执行；多写了configData，就会在configData变化时也触发加载，造成无限循环。

3.3 测试驱动的派生状态验证：如何写出真正可靠的单元测试

派生状态逻辑一旦出错，往往表现为“偶发性 UI 错乱”，很难复现。所以，测试必须覆盖所有状态转换路径。我们团队强制要求：每个使用getDerivedStateFromProps或自定义派生 Hook 的组件，必须有以下三类测试：

1. 初始渲染测试：验证组件挂载时，state 是否为预期值。
2. props 变化测试：模拟nextProps变化，验证getDerivedStateFromProps返回值是否正确。
3. 交互流程测试：模拟用户操作（如点击、输入），验证状态流转是否符合业务逻辑。

以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 问题速查表：高频故障现象与根因分析

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；而useState+useEffect会触发一次额外的 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