React表单：OnChange更新本地与Redux全局状态的性能对比

直接通过onChange更新Redux全局状态 #

• 性能层面：20个输入框的量级完全不用担心性能问题。Redux Toolkit（RTK）本身用Immer处理不可变更新，且默认的reducer更新只会触发依赖对应状态的组件重渲染。只要做两个基础优化：用React.memo包裹输入组件，或者在useSelector里精准获取需要的字段（别直接取整个实体对象），重渲染的范围会非常小，用户根本感知不到任何卡顿。我之前做过30+输入框的表单，直接更新Redux，流畅度没任何问题。
• 代码维护：完全符合DRY原则，不用维护本地状态和全局状态的同步逻辑，少写很多冗余代码。不用额外处理本地状态的更新、验证后的同步动作，代码简洁，后续改需求也不容易出状态不一致的bug。
• 额外优势：如果后续页面有其他组件需要实时用到表单输入值（比如实时预览、侧边栏统计），直接从Redux取就行，不用额外做状态传递。

本地状态暂存后同步到全局 #

• 性能优势：确实有一点，但20个输入框的场景下可以忽略不计。这种方案的核心价值从来不是性能，而是草稿保存（比如用户中途刷新页面，本地状态会丢失，可能需要结合localStorage）或者本地预验证（比如输入完所有字段后先做本地校验，没问题再同步到全局）。
• 缺点：需要维护两份状态，既要写本地的useState/useReducer处理输入更新，还要写同步到Redux的action和逻辑，代码冗余度高，容易出现“本地改了但没同步”“同步时漏字段”这类状态不一致的bug，后续维护成本更高。

最终建议 #

优先选择直接onChange更新Redux全局状态，20个输入框的场景下性能劣势完全可忽略，代码更简洁，维护更省心。如果实在担心重渲染，加个React.memo和精准的useSelector就足够了。只有当你有草稿保存、离线编辑这类特殊需求时，再考虑本地状态暂存的方案。

内容的提问来源于stack exchange，提问作者user19634493