能否将Redux的dispatch函数存入类中实现异步操作逻辑

这套写法本质上是绕开redux-thunk的标准化封装，自己在类里串联同步动作和异步流程，短期看代码路径很短，但项目规模上去后会遇到几类绕不开的问题：

• 重渲染带来的无意义对象创建与引用异常
  你在组件函数体里直接写const actions = new Actions(dispatch)，意味着组件每次重渲染都会生成一个全新的Actions类实例。如果后续把这个actions对象传给子组件、或者作为依赖项放进useMemo/useEffect的依赖数组，全新的对象引用会直接触发不必要的重复渲染、副作用重复执行，极端场景下会引发渲染死循环。同时高频率重渲染的页面里，反复生成实例也会带来不必要的内存开销。
• 完全缺失可测试性
  当前的类实现把dispatch引用、同步动作逻辑、异步请求方法全部硬编码在类方法内部，写单元测试时根本无法做依赖替换：你没法在不挂载完整Redux store的前提下，单独验证某个异步动作的执行流程——比如没法拦截dispatch调用校验动作类型是否正确、没法替换异步函数的模拟返回值验证异常分支、没法验证多步动作的触发顺序，最后要么只能写极其笨重的集成测试，要么彻底放弃对这部分逻辑的测试。
• 异步流程的消费能力不足
  即便你的异步方法本身是async函数，实际在业务场景里你经常需要在异步动作执行完成后做后续处理：比如请求成功后跳转路由、弹出操作成功提示、重置表单状态。现在的实现里，actions实例是在组件函数体里创建的，如果你要在异步完成后做后续逻辑，就得在组件的事件回调里自己加await，把本来封装好的异步逻辑又重新散落在组件代码里，失去了封装的意义。
• 错误处理的逻辑盲区
  当前的异步方法没有内置任何错误捕获逻辑，如果somethingAsync()抛出异常（比如接口请求失败、网络中断、参数校验不通过），这个错误会直接冒泡成未捕获的全局Promise异常：既不会触发你本该派发的"请求失败"类Redux动作来更新页面状态，也没法统一给用户做错误提示，严重时会直接导致页面白屏崩溃。
• 跨场景复用的限制
  当前的Actions实例是在React组件挂载时，依赖组件里的useDispatch()结果初始化的。如果你想在组件外的场景（比如路由拦截器、全局工具函数、非React环境的业务模块）触发同一套异步逻辑，根本拿不到已经初始化好的actions实例；如果强行把actions实例存在全局变量里，又会出现store引用泄漏、多store场景下dispatch错目标的问题。

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