使用CreateAsyncThunk拉取数据对比axios服务类的优缺点是什么？

createAsyncThunk是Redux Toolkit官方提供的异步流处理工具，它和基于axios封装的通用请求服务类定位不同，并不完全是替代关系，我们可以从适用/不适用两个维度判断使用时机：

应当使用createAsyncThunk的场景 #

• 项目已基于Redux Toolkit做全局状态管理，且接口返回数据需要存入全局store，供多个跨层级、非关联组件共享使用。createAsyncThunk会自动生成pending/fulfilled/rejected三类标准action，无需手动编写action定义、派发逻辑，仅需在extraReducers中对应处理状态更新即可，可大幅减少Redux异步场景下的重复模板代码
• 需要全局共享请求的加载、错误状态。比如多个页面/组件都需要感知同一个接口的加载状态、错误信息，使用createAsyncThunk可以直接把这类状态统一存在store中，无需每个组件单独维护重复逻辑
• 有复杂异步联动需求。比如请求前需要从store中获取用户token、地域配置等参数，请求完成后需要触发其他全局状态更新，或是需要支持请求取消能力，createAsyncThunk内置的thunkAPI参数可直接获取getState、dispatch、abortSignal等能力，无需额外封装传递相关方法
• 需要做全局统一的请求逻辑处理。比如统一的请求埋点、权限校验、错误上报，可配合Redux中间件直接监听createAsyncThunk生成的action做全局处理，无需在每个封装的axios请求中重复添加逻辑

不应当使用createAsyncThunk的场景 #

• 项目未使用Redux做状态管理，完全没必要为了使用createAsyncThunk额外引入Redux Toolkit，自定义封装的axios服务类足以覆盖需求
• 接口返回数据仅为单组件内部使用的私有数据，不需要共享给其他组件，也不需要全局维护请求状态。这种场景下直接在组件内调用封装好的axios方法，用useState维护加载、错误状态更轻量，不需要走Redux的全流程增加不必要的代码复杂度
• 只有非常简单的请求逻辑，不需要和全局状态联动、也不需要全局统一处理请求逻辑。这种场景下自定义axios封装已经足够灵活，引入createAsyncThunk反而会增加学习和维护成本，尤其是团队中不熟悉Redux的成员占比较高时

补充说明：实际项目中两者往往是配合使用的——把底层的请求封装、参数处理、响应格式化逻辑放在axios服务类中，createAsyncThunk仅负责调用服务类、处理和Redux store的交互逻辑，兼顾请求逻辑的复用性和Redux异步流的处理效率

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