Redux（React）：为何将修改状态的REQUEST action作为最佳实践？

作为资深开发者维护遗留Redux项目，还遇到Puppeteer测试因为渲染动画不稳定的问题，太懂这种既要兼顾旧代码规范又要解决实际痛点的纠结了。咱们一步步拆解你的问题：

一、为什么派发修改状态的REQUEST action是常规/最佳实践？ #

这个做法核心是为了用户体验和状态一致性，主要有这几个原因：

• 给用户即时反馈：比如分类页切换分类时，用户点了按钮如果没任何加载提示，会以为系统没响应，甚至重复点击。通过REQUEST action设置loading: true，可以让按钮置灰、显示加载动画，告诉用户“系统正在处理你的请求”。
• 避免状态混乱：如果上一次请求还在pending，用户又触发了新请求，REQUEST action可以用来清空旧数据或者标记当前请求的状态，防止新旧数据混在一起展示；同时也能用来拦截重复请求（比如判断loading为true时就不再派发新的请求）。
• 重置错误状态：如果上一次请求失败了，页面显示了错误提示，下一次发起请求时，REQUEST action可以把error状态清空，避免错误信息一直停留在页面上影响新的请求流程。

二、能不能跳过REQUEST action，只处理SUCCESS/FAILURE？ #

当然可以，但要先权衡利弊：

• 好处：减少一次全局状态更新，也就减少了关联组件的重渲染，刚好能解决你遇到的Puppeteer测试不稳定的问题（因为没有loading状态变化触发的动画干扰）。
• 坏处：
  1. 失去了全局层面的加载反馈，用户体验可能下降；
  2. 没法通过全局状态拦截重复请求；
  3. 上一次的错误状态无法及时重置，可能导致错误信息残留。

如果你的场景（比如分类页）用户对加载反馈的需求不强，或者可以用组件局部状态来做loading提示，完全可以跳过REQUEST action。

三、能否派发不修改状态的REQUEST action？ #

绝对可以！Redux的action本身只是一个带有type的普通对象，你完全可以派发一个{ type: 'FETCH_CATEGORIES_REQUEST' }，但在reducer里不处理这个action——这样既可以让redux中间件（比如redux-thunk、redux-saga）捕获到这个action，用来做请求日志、请求拦截等操作，又不会触发全局状态更新和组件重渲染。

这种方式的好处是：既保留了action的流程完整性（devtools里能看到完整的请求生命周期），又不会因为状态变化导致测试不稳定。

四、分类页这类场景，一定要在REQUEST阶段修改状态吗？ #

不是必须的！很多时候常规实践是为了覆盖大多数场景，但具体到你的项目（高性能要求、测试不稳定），可以灵活调整：

• 如果不想清空旧数据，可以不在REQUEST阶段重置数据，直到SUCCESS时再替换成新数据（用户切换分类时，旧数据会保留到新数据加载完成，避免页面空白）；
• 把loading状态从全局Redux状态移到组件内部，用useState来管理局部的loading，这样分类页的加载状态变化只会影响当前组件，不会触发全局的重渲染；
• 甚至可以完全跳过REQUEST action，只在SUCCESS/FAILURE时更新状态，同时用组件内部的loading来做用户反馈。

总结 #

你并没有忽略什么关键点，只是常规实践是为了通用的用户体验和状态管理，但在你的特定场景（高性能、测试不稳定）下，完全可以根据需求调整Redux的使用方式——毕竟工具是为业务服务的，不是反过来。

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