这可能是个冷新闻，所以标题很牛逼。

小程序的并发限制已经存在很长时间了，从第一个版本的5并发到后来的10并发。如果同时发出的请求数量超过这个限制，就会被残酷地抛弃，这就导致很多开发者在自己的项目中制造了“请求排队”的轮子。但事实上，早在一年半前，这个限制就被微信正式取消了。

10 个请求的并发限制

关于并发限制，在微信开发者文档中写道：

这个限制意味着同时wx.request、wx.uploadFile和wx.downloadFile的并发总数不能超过10个。

至今，仍有很多开发者一直遵守着这个规则。

很多人在写业务的时候都会小心翼翼的维护请求的数量。为了控制请求的数量，一些并行请求被专门改为串行请求，或者引入请求队列来维护applet请求。

这部分资深开发商遵守这一规则的努力，反映了他们早年在金额超标后要求被残忍抛弃的无奈。

applet基本库版本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个请求是同时发出的，后面请求的起点对应前一个请求的终点，可以反映请求的排队行为。

这意味着当并发请求较多时，要做好排队策略，根据请求的重要性和响应时间调整调用顺序，如果请求响应较慢，可以考虑做超时处理，以免等待较多而影响用户体验。