RTK Query中如何让endpoint.initiate()请求失败时抛reject异常？

RTK Query 派发 initiate thunk 默认不抛出异常、返回带error/data字段的结构化结果，核心是三个设计出发点：

• 对齐Redux核心行为：原生Redux dispatch thunk时，只有thunk内部主动返回rejected Promise才会触发抛错，RTKQ作为Redux生态内置工具，默认不改变dispatch的基础语义，避免给熟悉Redux的开发者造成预期偏差。
• 适配多场景状态处理需求：大部分场景下开发者需要同时处理加载、成功、失败三类状态，直接解构返回值的字段比try/catch语法更顺畅，也不会因为漏写catch导致未捕获异常全局冒泡。
• 保证内部状态流转可靠：无论请求成功还是失败，RTKQ都需要完成缓存状态写入、订阅更新、生命周期回调触发等内部逻辑，返回结构化结果可以保证这部分逻辑必然执行完毕，不会被外部的异常捕获逻辑意外中断。

initiate方法原生支持配置项，传入第二个参数设置throwOnError: true即可让请求失败时触发Promise reject，完全适配try/catch写法：

try {
  await dispatch(
    commentsApi.endpoints.myEndpoint.initiate(params, { throwOnError: true })
  )
  someOtherCallDependentOnMutationSuccess()
} catch (e) {
  // 捕获到的e和默认返回结构中的error字段完全一致，包含错误状态、错误信息等内容
}

目前RTKQ没有提供全局开关让所有endpoint.initiate()调用默认开启失败reject，官方也不推荐通过魔改源码、重写initiate方法的方式全局修改这个行为，原因如下：

• 一致性风险：RTKQ的缓存逻辑、自动生成的hooks、DevTools集成等周边能力，都是基于「默认返回结构化结果」的前提实现的，全局修改默认行为可能引发难以排查的隐性bug。
• 异常管控成本变高：如果默认抛错，所有漏写try/catch的调用在请求失败时都会触发未捕获Promise异常，轻则控制台报满错误，重则导致应用运行中断，尤其是多人协作的大型项目，这类问题的排查成本极高。
• 灵活性下降：很多场景不需要因为请求失败中断逻辑链，比如表单提交后无论成败都要关闭loading、上报埋点，这时候直接判断返回值的error字段比catch分支更直观，强制默认抛错反而会增加不必要的样板代码。

如果项目大部分thunk场景都需要用try/catch处理错误，完全可以自己封装一个通用的派发工具函数，统一传入throwOnError: true配置，不需要修改RTKQ的全局默认行为。

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