當你異步回調(diào)一個action時，如果不依賴這個異步返回的數(shù)據(jù)時，沒有問題。當要依賴返回的數(shù)據(jù)時就出問題了。
因為接口還沒返回，這個dispatch就已經(jīng)發(fā)出了。
所以在redux-thunk中，使用一個promise來對異步的處理。
你可以參考一下rudex-saga或者dva，都對異步做了很好的處理。

難道你以為thunk就不是異步回調(diào)之后手動dispatch一個action了么，最后修改store那個dispatch還不是要你自己寫。

thunk做的只是讓你的異步函數(shù)能夠以一種方便的形式拿到dispatch和store里的state而已，并沒有做很多事情，你看看源碼就是知道了。

首先，我不知道你入和對意義的定義？性能變好？代碼可讀性增加？擴展性變強？

If you’re not sure whether you need it, you probably don’t.
如果你處于這個階段，你可以選擇不用，官方描述。

你覺的你當前代碼寫的很舒服，那么為什么需要額外的引入你不了解的東西呢？當然不需要

想要知道thunk有沒有意義?可以先從文檔上了解

這是thunk的motivation
Redux Thunk middleware allows you to write action creators that return a function instead of an action

就是你可以dispatch(function)。

下來談談你的問題，不可以在異步回調(diào)之后直接手動dispatch一個action嗎？

當然可以。你在異步回調(diào)之后直接dispatch，這可以啊，我覺的沒什么不好。

這里主要看你對action的定義，就以網(wǎng)絡請求為例，列個簡單比較。

xxxAction(xxxData) {
    return {
        type: xxxType,
        data: xxxData
    }
}

// 直接放在你需要使用的地方
fetchXxxData().then((res) => {
    dispatch(xxxAction(xxx))
})

這種情況下，你將你xxxAction定義為一個通過數(shù)據(jù)來修改store數(shù)據(jù)的action

getXxxDataAction() {
    return (dispatch) => {
        fetchXxxxData().then((res) = > {
               dispatch(xxxAction(res))
        })
    }
}

使用方式
store.dispatch(getXxxDataAction())

這種情況下，你將這個getXxxDataAction定義為一個從后臺獲取數(shù)據(jù)變修改store庫中的Action

其實你會發(fā)現(xiàn)這兩個寫法基本是一致的，上面那種方法是沒有問題的。上面的方法可以看做是下面方法的解耦。解除了請求和修改store之間的關系。所以根本沒有什么非得用誰，只是你當前的場景適合用誰。

下面方法的好處是什么，就是比如我在這個系統(tǒng)中，我的請求和修改數(shù)據(jù)的關系是恒定不變的，那么我不解耦的用法可能會更加的舒服。比如

A 需要獲取xxx數(shù)據(jù)，并存入store中。
B 也需要獲取xxx數(shù)據(jù)，并存入store中。

下面這種只需要在兩個組件中去添加這句store.dispatch(getXxxDataAction())
而上面那種就必須把請求以及回調(diào)來重復寫一遍，同樣的代碼兩個路口，一旦涉及到需要修改的時候，就很容易會遺漏