微信小程序解除 10 個請求併發限制了？！

這多是一個冷消息，因此標題比較勁爆。

小程序併發限制由來已久，從剛發佈時的 5 併發，到後來的 10 併發，同時發出的請求數若超出這個限制則將被殘忍拋棄，由此催生了不少開發者在本身的項目中造了「請求排隊」的輪子。然而事實上，早在一年半之前，該限制就被微信官方取消。

10 個請求的併發限制

關於併發限制，微信開發者文檔中是這麼寫的：

這一限制的意思是在同一時刻， wx.request、wx.uploadFile、wx.downloadFile 加起來的併發總數不能超出 10 個。

至今，仍有不少開發者一直遵照着這個規則。

許多人在寫業務的時候當心翼翼地維護着請求數。爲了將請求數控制好，特意將一些並行請求改成串行，或者引入請求隊列來維護小程序請求。

這部分資深開發者爲了遵照這一規則所花的功夫，多少反映出了早年他們在面對數額超出後請求被殘忍拋棄時的無奈。

附小程序基礎庫版本 1.3.0 的控制檯報錯:

時至今日，仍有開發者在討論解決小程序併發限制的方法：

被忽略的消息

實際上，微信在 2017 年 7 月的基礎庫 1.4.0 版本升級中就作了優化，對超過併發限制的請求作了隊列處理，只是還有不少開發者並不知道這一消息。

從嚴格意義上來講，這次優化並無徹底解除原有的併發限制。目前同時處理請求的上限還是 10 個，但在 10 個之外的請求會排隊，當前面有請求完成的時候，隊列中的請求按順序發送並處理，*不會像以前那樣直接將超出 10 個的請求丟棄。

附件小程序基礎庫 1.4.0 更新日誌（部分）：

如今，咱們終於能夠忽略請求併發限制，愉快地發送請求了。畢竟請求都是能夠都發送出去的，只不過在效率上會比無併發限制的狀況慢一些。

發送請求的正確姿式

如上文所說，微信小程序是在基礎庫 1.4.0 版本中加入對超過併發限制的請求作隊列處理優化的，在 1.4.0 如下的版本中超出併發部分的請求會被丟棄。

據微信官方數據，截止到 2018 年 12 月，1.4.0 版本如下用戶佔比大約是 0.04%，雖然目前小程序不多會兼容到這麼低的版本，可是對一些有特殊須要的小程序也要注意基礎庫的差別。

另外要注意的是小程序併發請求的排隊機制。當同時調用的請求超過 10 個時，小程序會先發起 10 個併發請求，超過 10 個的部分按調用順序進行排隊，當前一個請求完成時，再發送隊列中的下一個請求。

附 20 個請求併發測試：

測試結果：

從圖中能夠看到，前 10 個請求同時發出，然後面的請求的起始點，對應了前面某個請求的結束點，能夠反映出請求的排隊行爲。

這意味着，在併發請求不少的時候應該作好排隊策略，按請求的重要程度和響應時間調整調用順序，若是遇到請求的響應很慢的狀況，能夠考慮作 timeout 處理，以避免大量等待，影響用戶體驗。

搜索關注公衆號「知曉雲」，讓你的小程序開發快人一步。