当前位置：首页 > news >正文

redux-thunk和createAsyncThunk

news 2026/5/12 11:27:02

d8c7486e9563e9b235c8ebc670b152ba
05ad9a26216468fc7a01ee14b56e086f
fce6371be109ead1911f8bd256ed86a2
dbd5ffdf23e59c51a8d3f109289c8453
你提到了一个非常有趣且常见的观点！

许多开发者确实认为，从“编写和阅读”异步逻辑的角度来看，手写 redux-thunk 的 async (dispatch) => {...} 形式，比 createAsyncThunk 更加直接和直观。

⚖️ 两种异步写法的“体感”对比

让我们来分析一下为什么你会有这种感觉：

1. 手写 Thunk (`redux-thunk` 模式)

// 你觉得简洁易懂的写法
export const fetchItems = () => async (dispatch) => {dispatch({ type: 'fetch/pending' }); // 手动 dispatch 状态try {const response = await api.getItems();dispatch({ type: 'fetch/fulfilled', payload: response.data }); // 手动 dispatch 成功} catch (error) {dispatch({ type: 'fetch/rejected', payload: error.message }); // 手动 dispatch 失败}
};

优点（体感舒服的原因）： 流程清晰，是标准的 JavaScript try/catch/await 结构，你完全控制每一个 dispatch 的时机和内容。
缺点： 样板代码多，pending, fulfilled, rejected 这三个 Action Type 必须手动编写并保持同步，容易出错。

2. `createAsyncThunk` 模式 (RTK 推荐)

// RTK 推荐的 createAsyncThunk 结构
export const fetchItems = createAsyncThunk('fetch/items', // Action Type 基础名async (userId, thunkAPI) => {// 异步回调：只需返回 Promise 结果const response = await api.getItems(userId);return response.data; // 成功时返回的数据}
);
// 状态更新逻辑在 createSlice 的 extraReducers 中
// builder.addCase(fetchItems.fulfilled, (state, action) => { ... })

优点（RTK 推荐的原因）： 极大地减少了样板代码。你只关注 "如何获取数据"，而不用关注 "如何更新状态"。状态更新的逻辑被移到了 extraReducers 中，实现了更好的 职责分离。
缺点（体感不舒服的原因）：
- 流程分散： 异步逻辑（createAsyncThunk）和状态更新逻辑（extraReducers）被分开了，你必须在两个不同的地方查看完整的逻辑。
- 魔法感： 你没有看到 dispatch 的过程，需要理解 RTK 在幕后自动完成了 Action 的创建和派发。

总结

你的感觉非常正常。选择哪种写法，通常是 “代码直观性” 与 “减少重复” 之间的权衡：

风格	优势	劣势
手写 Thunk	流程直观，易于理解和调试。	大量重复的 `try/catch` 和 `dispatch` 逻辑。
`createAsyncThunk`	极致简洁，零样板代码。	逻辑分散（异步在 `thunk`，更新在 `extraReducers`）。