有道理 :)

我到觉得官方要做到的是丰富更多可能的接口，因为一个需求接口说不定就能满足到好多人。  的确现阶段我在做的事就是你刚说的那样去优化服务器，但是数据链接是双向的我想更多的满足当用户在网络环境差的时候，让体验不会那么糟糕。 就比如超时设置，其实或许很多时候设置的时间到了，而这个时候用户加载已经完成90%了。 但因为设了超时，中断了。 假设我这时候能做到 设个取消按钮。让用户自己选择等待还是退出就完美了

“退出当前页面即中断 request 请求”这个肯定是不会有的，因为它会带来更多的问题，会干扰其它场景下的正常逻辑。

如果官方推出一个 wx.cancelRequest 接口，你会用吗？想想都觉得这个会非常难用。

所以，真正有效的手段还是改善服务器响应能力，不要每个请求都花那么长的时间，另外如果必要的话，缩短 request 的超时时间，比如设置成 5 秒，那么，用户想必无法做到在 5 秒之内触发第 6 次 request，呵呵

说到底，如果用户连续遇到 5 次 request 都不能及时响应的情形，那么对他来说这其实就已经是“宕机”了。

所以，按理说我们一般的网络页面，后退了即中断了链接了，这样就不会响应堆积在一起。用户只要不退出耐心等待。还是能成功打开页面的。可现在小程序 后退没有中断，如果用户前期不耐心超过5次响应堆积了。后续想耐心也没法了。加上小程序关闭在进入也并不会终止掉，我现在能做的只能是给个超时设置，请求超过多少秒，才给中止。

如果用户分别进入 5 个页面，触发的 5 次 request 都没有及时响应而堆积在一起，那这个时候就算没有 request 的次数限制也跟“宕机”差不多了呀。

如果没有限制最高只能请求5次还好，可限制了只能5次，用户网络访问比较慢的时候，后退点了其他请求，进去还是很慢，他又退出，这样当请求超过5个了。后面就点击不起作用了。用户就会以为我们程序宕机没法用了

很正常啊……