为何Redux-Form的onSubmit验证需节流？模拟服务端延迟必要性存疑

一、为什么需要对onSubmit验证进行节流处理？ #

给onSubmit验证（或者说整个提交处理器）做节流处理，在实际应用里有几个核心作用：

• 避免重复请求/重复验证：如果用户快速多次点击提交按钮（可能是误触，也可能是没看到即时反馈以为没提交成功），你的验证逻辑（尤其是涉及服务端调用的）会反复触发。这不仅浪费服务器资源，还可能引发竞态问题——比如第一次验证的响应可能比第二次晚返回，导致UI显示冲突的状态。
• 稳定Redux Store状态：Redux-Form会在Redux Store里管理submitting、pristine这类提交相关状态。没有节流的话，频繁的提交点击会让这些状态快速来回切换，导致UI出现卡顿（比如加载 spinner 不停闪烁）或者表单意外重置的问题。
• 提升用户体验：节流能确保用户的操作只会被处理一次，哪怕他们点了多次。这避免了用户困惑，同时让UI在验证或提交过程中表现得更可预测。

通常的做法是提交开始后就禁用提交按钮，但节流相当于再加一层防护，防止禁用逻辑失效或者更新不及时的情况。

二、为什么Redux-Form文档要求在验证函数中模拟服务端延迟？ #

文档推荐模拟服务端延迟是为了贴合真实场景，哪怕你的应用现在不加延迟也能正常运行，这背后的原因很关键：

• 为真实服务端交互做准备：本地验证是瞬间完成的，但当你切换到服务端验证（比如校验邮箱是否唯一、密码是否符合数据库规则这类关键检查几乎都需要），必然会有网络延迟。模拟延迟能帮你提前处理异步状态——比如显示加载提示、禁用表单、或者在等待响应时阻止重复提交。
• 提前发现边缘情况：不加延迟的话，你可能注意不到只有在验证耗时较长时才会出现的问题，比如竞态条件、UI状态不一致、未处理的Promise拒绝。举个例子，如果你的代码默认验证瞬间完成，可能会忘记处理pending状态，等到真实服务器响应变慢时，用户体验就会大打折扣。
• 培养异步思维习惯：当涉及服务端验证时，Redux-Form的提交流程本身就是异步的。模拟延迟能强迫你正确使用Promise、async/await或者Redux Thunk，确保代码足够健壮，能应对生产环境的复杂情况。

你的应用现在能正常运行，大概率是因为只用了纯客户端验证、没有网络调用，但文档是在引导你为完整的真实场景做开发准备。

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