为什么使用Redux Thunk dispatch异步action而非先请求后dispatch？

你提到的两种写法本质是异步逻辑的存放位置不同，核心区别可以通过代码对比直观体现：

方案1：异步逻辑写在dispatch的外层（比如组件内部），await异步结束后再dispatch同步action

// 组件内代码
const handleGetUser = async () => {
  try {
    const res = await fetch('/api/user/1')
    const userData = await res.json()
    // 异步完成后才 dispatch 携带数据的同步action
    dispatch(setUserInfo(userData))
  } catch (err) {
    console.error(err)
  }
}

方案2：用thunk中间件dispatch异步action，异步逻辑封装在action creator内部

// 独立的action模块代码
export const fetchUserInfo = (userId) => async (dispatch) => {
  // 可以在异步请求的任意阶段dispatch，比如请求开始前更新loading状态
  dispatch(setLoading(true))
  try {
    const res = await fetch(`/api/user/${userId}`)
    const userData = await res.json()
    dispatch(setUserInfo(userData))
  } catch (err) {
    dispatch(setFetchError(err.message))
  } finally {
    dispatch(setLoading(false))
  }
}

// 组件内只需要一行调用
dispatch(fetchUserInfo(1))

两者的核心差异点：

• 逻辑耦合度：方案1的异步逻辑和当前组件强绑定，要复用只能重复写代码，或者额外抽函数还要手动传dispatch；方案2的整套异步逻辑（请求、异常处理、状态更新）完全封装，任意组件都可以直接dispatch复用。
• 状态管理范围：方案1的loading、错误状态如果要全局使用，需要额外同步到store，否则只能当前组件访问；方案2所有和请求相关的状态更新都在action内部完成，直接存入全局store，所有组件都可以订阅使用。

• 异步逻辑需要复用：如果同一个请求逻辑（比如获取当前登录用户信息、提交通用表单）需要在多个组件、多个业务模块调用，用thunk只需要写一次就能随处调用，避免重复代码。
• 需要管理异步全流程状态：如果需要全局共享请求的loading、错误状态，比如全局顶部的加载条、全局错误提示，异步action可以在请求的任意阶段dispatch更新状态，不需要外层逻辑关心中间流程。
• 需要处理复杂异步逻辑：比如串行多请求（先拿用户ID再拉取用户订单）、请求防抖、请求取消、根据全局状态判断是否要发请求（已有缓存就跳过请求），这些逻辑都可以直接写在thunk内部，不需要组件感知：

// 自带缓存判断的异步action示例
export const fetchUserInfo = (userId) => async (dispatch, getState) => {
  // 直接从全局store取缓存，存在缓存就不发请求
  const cachedUser = getState().user.cache[userId]
  if (cachedUser) {
    dispatch(setUserInfo(cachedUser))
    return
  }
  // 剩余请求逻辑...
}

• 方便单元测试：异步action可以脱离组件单独测试，只需要模拟dispatch、getState方法，就能验证整套异步流程的逻辑是否正确，不需要依赖组件渲染环境。

如果是仅在单个组件使用的一次性简单请求，不需要复用逻辑，也不需要把loading、错误等状态存入全局store，用你提到的写法完全没问题，反而更简洁，没有必要为了使用thunk强行加额外代码。

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