微信小程式的10個請求並發限制的最佳化訊息！ ！ ！

本篇文章帶給大家的內容是關於微信小程式的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 處理，以免大量等待，影響使用者體驗。

以上是微信小程式的10個請求並發限制的最佳化訊息！ ！ ！的詳細內容。更多資訊請關注PHP中文網其他相關文章！