基于React Hooks开发的应用是否真的需要Redux Thunk中间件？

你提到的两种写法都是可行的，在简单场景下确实不需要使用redux-thunk也能完成Redux的异步更新，你没有遗漏基础用法。但redux-thunk的核心价值体现在更复杂的项目需求中，不能被组件内直接请求的写法完全替代：

• 异步逻辑复用：如果同一个异步更新逻辑（比如拉取当前登录用户信息）需要在多个组件、多个路由中触发，写在组件useEffect中的请求、错误捕获、状态分发逻辑需要多次重复编写。如果封装成独立的thunk函数，只需要在需要的位置执行dispatch(getUserFromApiAndDispatch())即可调用，不需要重复实现内部逻辑。
• 逻辑解耦与可测试性：当异步逻辑复杂度上升后，比如需要前置判断缓存是否有效、串行/并行发起多个关联请求、处理请求竞态、控制全局loading/错误状态等，把这些逻辑都写在组件内会导致组件代码臃肿，和UI逻辑耦合严重，难以单独测试业务逻辑。thunk可以把这部分纯业务逻辑抽离到独立的action层，不需要渲染组件就可以完成单元测试。
• 统一流程管控：你可以在thunk层封装统一的错误上报、请求重试、权限拦截逻辑，不需要每个组件的useEffect中单独实现相关能力，减少重复代码。
• 团队协作规范：对于多人协作的中大型项目，约定所有修改Redux状态的异步逻辑都通过thunk实现，能让代码结构更清晰，所有状态变更的逻辑都收敛在同一层，方便排查问题和新人接手。

如果你的项目规模很小、异步逻辑非常少且不存在复用需求，完全可以不用引入redux-thunk，直接在组件内发请求后分发普通action即可，没有必要强行引入额外依赖。

两种异步更新Redux的实现示例 #

redux-thunk实现方案 #

const Component = () => {
  const dispatch = useDispatch()
  const user = useSelector(state => state.user)

  useEffect(() => {
    dispatch(getUserFromApiAndDispatch())
  }, []) 

  return <div>{user}</div>
}

组件内直接请求实现方案 #

const Component = () => {
  const dispatch = useDispatch()
  const user = useSelector(state => state.user)

  useEffect(() => {
    getUserFromApi().then(({data}) => dispatch({type: 'SET_USER', payload: data.user}))
  }, []) 

  return <div>{user}</div>
}

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