1.不會(huì)多次返回登錄，你發(fā)出的第一個(gè)請(qǐng)求判斷到token失效之后，調(diào)整到了登錄頁(yè)，那么后面的都沒(méi)都不會(huì)再執(zhí)行
2.在返回之前可能有多個(gè)請(qǐng)求已經(jīng)發(fā)出了，但是返回是只會(huì)執(zhí)行一次

我來(lái)補(bǔ)充一下吧 ，最后 promise.all 基本能解決這個(gè)問(wèn)題

我猜你這個(gè)場(chǎng)景應(yīng)該是客戶端路由加上頁(yè)面上多個(gè)組件自己發(fā)起fetch吧？

建議封裝fetch功能為公共對(duì)象，各個(gè)組件統(tǒng)一調(diào)用，對(duì)于身份異?？梢越y(tǒng)一處理，這樣當(dāng)?shù)诙€(gè)異常要跳轉(zhuǎn)時(shí)很好處理了。最簡(jiǎn)單辦法你可以設(shè)置一個(gè)標(biāo)志，第一個(gè)跳了置true，后面的看到了就不要跳。然后身份處理好了標(biāo)志置false。

我的方案是用高階組件+redux解決問(wèn)題。
首先所有的接口都走redux，數(shù)據(jù)正常該dispatch哪去dispatch哪去。如果登錄失敗 dispatch 一個(gè)登錄失敗的action，然后在高階組件中處理登錄問(wèn)題，如果找不到登錄態(tài)，那么就跳轉(zhuǎn)登錄頁(yè)，如果有登錄態(tài)就什么都不做。
注意：不要在reducer中dispatch，登錄頁(yè)本身不要被高階組件包裹

然后就是審美問(wèn)題了 withRouter(connect(state=>state)(LoginHOC(YourBusiness)));
就是長(zhǎng)了一點(diǎn)而已嘛。。。

其實(shí)我也就是隨便一答，redux管理接口，確實(shí)能做到頁(yè)面視圖完全解藕，但是你們知道接口異常打一個(gè)toast有多麻煩。先dispatch到redux，過(guò)幾秒鐘還要在dispatch一個(gè)cancelToast

我也在等待更好的接口管理方式。有時(shí)挺矛盾的 復(fù)用行就以為這解藕，引入了三方狀態(tài)和subscription，然后再map到自己的狀態(tài)，解了藕肯定會(huì)造成不方便。

ps： 一些腦回路輕奇的同事，讓ajax模塊接受一個(gè)this，然后就能操作頁(yè)面了，我勒個(gè)去。。。那還不如Vue的mixin思想。