作者：Sunshine_Lin

簡介：「前端之神」的號主江湖人稱林三心，現已有100+篇原創文章，全網粉絲高達1w+，面試過超過100+個前端程式設計師，全網獲贊2w+，全網閱讀量播放量超過60w，更是B站「面試進階成為大佬」系列影片的Up主。喜歡分享Vue，React，Typescript等高階前端知識。

前言

大家好，我是林三心，用最通俗易懂的話講最難的知識點是我的座右銘，基礎是進階的前提是我的初心，眾所周知哈， Promise 在咱們的開發中是相當的重要，我覺得對於Promise的使用等級，可以分為三個等級。

1、掌握 Promise 的基本使用

2、掌握 Promise 的基本原理

3、在專案中能靈活運用 Promise 解決一些問題

第一點的話，其實就是能掌握 Promise 的一些基本使用方法以及一些方法，如 then、catch、all、race、finally、allSettled、any、resolve 等等。

第二點的話，就是要能簡單實現一下 Promise 的原理，這能使我們對Promise的那些常用方法有更好的理解。

第三點的話，就是要能靈活Promise解決咱們開發中的一些問題，今天我就給大家說一下我用Promise在專案開發中解決了什麼問題吧！

介面請求超時

顧名思義，就是給定一個時間，如果介面請求超過這個時間的話就報錯。

1、自己實現

實現思路就是： 介面請求 和 延時函式 賽跑，並使用一個Promise包著，由於Promise的狀態是不可逆的，所以如果 介面請求 先跑完則說明 未超時 且Promise的狀態是fulfilled，反之， 延時函式 先跑完則說明 超時了 且Promise的狀態是rejetced，最後根據Promise的狀態來判斷有無超時。

2、Promise。race

其實 timeoutPromise 中的程式碼可以使用 Promise。race 來代替，是同樣的效果。

3、測試

轉盤抽獎

我們平時在轉盤抽獎時，一般都是開始轉動的同時也發起介面請求，所以有兩種可能。

1、轉盤轉完，介面還沒請求回來，這是不正常的

2、轉盤轉完前，介面就請求完畢，這是正常的，但是需要保證 請求回撥 跟 轉盤轉完回撥 同時執行

1、轉盤轉完，介面還沒請求回來

主要問題就是，怎麼判斷 介面請求時間 是否超過 轉盤轉完所需時間 ，咱們其實可以用到上一個知識點 介面請求超時 ，都是一樣的道理。如果 轉盤轉完所需時間 是2500ms，那咱們可以限定 介面請求 需要提前1000ms請求回來，也就是 介面請求 的超時時間為2500ms - 1000ms = 1500ms。

2、轉盤轉完前，介面就請求完畢

咱們確保了 介面請求 可以在 轉盤轉完 之前請求回來，但是還有一個問題，就是需要保證 請求回撥 跟 轉盤轉完回撥 同時執行，因為雖然 介面請求 請求回來的時候，轉盤還在轉著，咱們需要等轉盤轉完時，再一起執行這兩個回撥。

聽到這個描述，相信很多同學就會想到 Promise。all 這個方法。

3、測試

控制併發的Promise的排程器

想象一下，有一天你突然一次性發了10個請求，但是這樣的話併發量是很大的，能不能控制一下，就是一次只發2個請求，某一個請求完了，就讓第3個補上，又請求完了，讓第4個補上，以此類推，讓最高併發量變成可控的。

實現

測試

取消重複請求

舉個例子，咱們在做表單提交時，為了防止多次重複的提交，肯定會給按鈕的點選事件加上 防抖措施 ，這確實是有效地避免了多次點選造成的重複請求，但是其實還是有弊端的。

眾所周知，為了使用者更好地體驗， 防抖 的延時是不能太長的，一般在我的專案中都是 300ms ，但是這隻能管到 請求時間 < 300ms 的介面請求，如果有一個介面請求需要 2000ms ，那麼此時 防抖 也做不到完全限制 重複請求 ，所以咱們需要額外做一下 取消重複請求 的處理。

實現

實現思路：簡單說就是，利用Promise。race方法，給每一次請求的身邊安裝一顆雷，如果第一次請求後，又接了第二次重複請求，那麼就執行第一次請求身邊的雷，把第一次請求給炸掉，以此類推。

測試

全域性請求loading

比如一個頁面中，或者多個元件中都需要請求並且展示 loading狀態 ，此時我們不想要每個頁面或者元件都寫一遍 loading ，那我們可以統一管理 loading ， loading 有兩種情況。

1、全域性只要有一個介面還在請求中，就展示 loading

2、全域性所有介面都不在請求中，就隱藏 loading

實現

測試

參考