在现代前端开发中，React 已经成为构建用户界面的主流框架之一。随着应用的不断复杂化，有效管理组件状态成为保证代码可维护性与性能的关键环节。在 React 中，状态（State）既是决定组件数据变化的核心，也是触发视图更新的重要因素。传统做法中，开发者往往会试图同步多个相关状态，但这种方法容易引发状态不一致、难以维护等问题。Kent C. Dodds 提出的“不要同步状态，派生状态”理念，深刻改变了我们对 React 状态管理的理解和实践。本文将系统剖析该理念的核心思想、优势以及落地实现，助你提升 React 应用的稳定性和代码简洁度。
状态管理中的“同步”陷阱在实际开发中，开发者经常面对需要维护多个相互关联的状态变量。例如构建一个经典的井字棋游戏，除了承载棋盘格局的数据（squares），还存在判断获胜者（winner）、计算下一个行棋者（nextValue）以及展示当前游戏状态（status）等多重状态变量。常见做法是使用React的useState 钩子分别管理这些状态变量。虽然表面上看这一做法合理，但它带来一个重大隐患：所有状态都属于“基本状态”，但它们之间又存在紧密的关联关系，winner、nextValue、status 实际上都是由 squares 派生得出。如果每次更新 squares 时，不同步地更新这些衍生状态，就会导致状态脱节，产生错误显示或业务逻辑混乱。同步多个状态变量，不仅需要频繁地调用多个setState，代码冗余，维护复杂性也急剧增加。
如果考虑扩展游戏功能，比如允许一次选中两个格子，则更新逻辑变得更加复杂，更加容易出现遗漏，进而造成状态不一致。派生状态的本质及其优势派生状态指的是：某些状态并不会单独存储，而是根据其它状态实时计算而得。例如，在井字棋游戏中，nextValue、winner、status 并非独立管理，而是直接通过函数 calculateNextValue、calculateWinner、calculateStatus 计算得出。在 React 的每次渲染中，借由 props 或基础状态实时计算派生状态，可以避免状态同步引发的问题。派生状态极大简化了状态管理逻辑，降低了出现同步错误的风险，让代码更简洁。这里，只有 squares 是用于触发组件重新渲染的唯一单一状态；与之相关联的状态均来源于它，因此避免了状态之间的“竞态条件”或不一致情况。
派生状态在组件层面呈现出纯函数思想，具有更好的可预测性。同时，丰富的状态更新逻辑被简约化为状态的单一源头，访问和修改都更为直观明了。实现派生状态的典型写法示例如下，组件中仅定义基础状态 squares，通过调用函数直接获得 nextValue、winner 和 status，省略对它们的额外 useState 管理，且无需明确同步更新操作。这样，selectSquare 函数仅需直接更新 squares 状态即可。 function Board() { const [squares, setSquares] = React.useState(Array(9).fill(null)) const nextValue = calculateNextValue(squares) const winner = calculateWinner(squares) const status = calculateStatus(winner, squares, nextValue) function selectSquare(square) { if (winner || squares[square]) return const squaresCopy = [...squares] squaresCopy[square] = nextValue setSquares(squaresCopy) } // 返回 JSX } 该写法不仅使代码简洁，而且天然避免了状态间的冲突和更新遗漏。useReducer中维护派生状态的思考useReducer 作为 React 中管理复杂状态的另一选择，通过集中处理状态更新，能够将基础状态及其派生逻辑集成在一个 reducer 函数中。
在上述井字棋例子中，可以将所有状态状态（squares、nextValue、winner、status）封装在 reducer 返回的单一状态对象里，实现更加确定且集中式的状态更新。每次分发更新动作都会通过 reducer 重新计算所有派生状态，确保各状态之间的一致性和准确性。事实上，如果项目中的状态逻辑较为复杂，或者需要保证不同来源的状态变动间不会出现冲突，useReducer 的集中式管理无疑提供了一种清晰而可靠的方案。不过相对而言，复杂度稍高，开发者需要权衡清晰度与简洁性之间的关系。传入状态的派生实践如果组件从父组件接收状态（例如 squares）作为 props，之前同步更新派生状态的做法变得尤为繁琐：如何确保派生状态在 props 变更后及时更新，通常会用到useEffect 或其他副作用钩子。这不仅增加了代码复杂度，同时容易引入副作用和竞态问题。
此时，更为优雅的做法依然是直接计算派生状态，即在函数组件体内直接调用计算函数，传入 props。这样，组件通过 props 获得基础状态，并基于此派生其他状态，避免不必要的额外状态管理和副作用调度。性能优化与 useMemo的角色性能是许多开发者关注的核心问题。担心频繁的派生计算成为性能瓶颈，往往会陷入过度优化的误区。实验证明，现代 JavaScript 引擎执行这些计算函数（如 calculateWinner）速度极快，普通应用场景难以构成性能瓶颈。但如果你确实遇到计算昂贵的函数或较大数据规模的计算，可以借助 React 的 useMemo 钩子函数缓存计算结果，仅在依赖数据变化时重新计算，降低不必要的开销。
例如： const nextValue = React.useMemo(() => calculateNextValue(squares), [squares]) const winner = React.useMemo(() => calculateWinner(squares), [squares]) const status = React.useMemo(() => calculateStatus(winner, squares, nextValue), [winner, squares, nextValue]) 这一优化提升了性能的同时，也保持了代码易读性。切记先通过性能监测确认瓶颈，避免过早优化。高级派生状态管理工具展望例如 Redux 的 Reselect 和 MobX 的 computed values，都提供了状态的智能派生及缓存机制。它们不仅能实现高效的派生状态计算，还能延迟计算直到必要时执行，极大提升状态管理体验和性能。这些库适用于复杂、大型应用，有着更完善的生态和工具支持。对小型或中等复杂度项目而言，简单的手工派生状态即可满足日常需求。
总结React 状态管理的核心在于理解什么状态需要被“管理”（即存储在 state 中），什么状态应当被“派生”（即基于现有状态实时计算）。尝试尽可能少地存储状态，只存储基础状态是防止 inconsistency 的关键。派生状态不仅让代码更简洁，避免了同步更新中常见的 bug，也往往带来更好的性能表现，尤其是在避免不必要的渲染和计算的场景下。通过实践派生状态的理念，开发者可以提升 React 应用的稳定性、易维护性及性能表现。对未来编码实践而言，养成区分基础状态与派生状态的习惯，是构建高质量 React 应用不可或缺的技能。
