这可能是个冷新闻，所以标题挺刺激的。

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

并发限制为10个请求

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

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

到目前为止，很多开发人员一直遵循这个规则。

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

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

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

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

以上就是本文的全部内容。希望对大家的学习有帮助，支持我们。