为什么useEffect需要将dispatch传入依赖数组？与空依赖写法有何差异？

通过react-redux的useDispatch拿到的dispatch函数，默认是引用稳定的——这是官方做的常驻优化，不会随组件普通重渲染改变引用。

为什么要把dispatch传入useEffect的依赖数组 #

• 符合Hooks规范的强制检查要求：只要是在useEffect回调作用域内引用的、来自组件作用域的变量或函数，react-hooks/exhaustive-deps插件都会要求将其纳入依赖列表。这条规则的设计逻辑是不预判值的稳定性，避免开发者写出隐式依赖的闭包陷阱，漏写时插件会直接抛出警告。
• 覆盖极端场景的引用变化风险：虽然日常生产环境下dispatch引用稳定，但遇到以下情况时引用确实会更新：
  • 开发环境启用Redux热模块替换（HMR），替换底层store实例时
  • 自定义封装的dispatch逻辑随外部状态变化，重新生成了函数引用
    这种场景下如果不把dispatch纳入依赖，effect会一直持有最初的旧闭包引用，调用时可能出现store失效、状态读取错误的问题。

两种写法的实际区别 #

写法一（依赖数组为[dispatch]） #

useEffect(() => { dispatch(fetchTodo()); }, [dispatch])

• 执行逻辑：只有当dispatch的引用发生变化时，才会重新执行副作用内的fetchTodo请求。在绝大多数dispatch引用稳定的场景下，这个逻辑只会在组件首次挂载时执行一次，不会因为组件普通重渲染触发多余请求。
• 合规性：完全符合ESLint Hooks检查规则，不会弹出依赖缺失的警告。

写法二（空依赖数组[]） #

useEffect(() => { dispatch(fetchTodo()); }, [])

• 执行逻辑：完全忽略dispatch的引用变化，无论组件重渲染多少次、dispatch是否换了新的引用，都只会在组件首次挂载时执行一次请求。
• 潜在风险：
  • 遇到前面提到的dispatch引用变化场景时，空依赖effect会固化持有最初的旧dispatch闭包，可能出现调用报错、状态读取陈旧的问题
  • 因为依赖声明不完整，ESLint规则会持续抛出警告，长期积累容易让团队忽略规则提示，遗漏真正需要声明的依赖项，埋下闭包陷阱的隐患

内容的提问来源于stack exchange，提问作者Trung Thăng Nguyễn