• 需求的场景描述（希望解决的问题）

小程序提供API接口大部分都是异步接口，但是有些接口又依赖于其他接口的调用结果，这就造成为了实现一个接口调用需求而进行多层代码嵌套，代码相当不美观，也不利于开发者维护。

例如：要获取当前连接的WiFi信息，则需要三个API的嵌套调用来实现获取WiFi信息，然后再与服务器进行交互：

wx.getNetworkType({ //获取当前网络类型   success(res) {     const networkType = res.networkType     if (networkType === 'wifi') {//判断是wifi环境       wx.startWifi({ //初始化WiFi         success(res) {           console.log(res.errMsg)           wx.getConnectedWifi({ //获取WiFi信息             success(res) {               console.log(res.errMsg)               wx.request({ //信息获取成功，与服务器进行交互                 url: 'test.php', //仅为示例，并非真实的接口地址                 data: {                   x: '',                   y: ''                 },                 success(res) {                   console.log(res.data)                   //服务器返回成功后进行页面处理                   //TODO                 }               })             }           })         }       })     }   } })

以上代码除了繁琐不美观之外，还不利于维护

• 希望提供的能力

希望官方团队能将异步API实现可指定异步或同步，或者是将API封装成Promise对象，这样开发者可方便自由的通过Promise对象来模拟异步同步，还可以简化接口嵌套，简化代码，方便维护。

之所以希望官方团队将异步API封装成Promise对象而不是自己去封装，是基于良好的版本升级的考虑，如果是自己去封装，万一某次版本升级将某些API改变或者废弃，或者新增某些API，这对于开发者来说，去维护自己的封装也将是很大的开发成本。

既然小程序支持ES6的转码，那么，个人认为，如果官方团队能将所有的异步API升级为返回Promise对象，那将是对开发者相当友好的一件事，会增加开发者的热情和积极性，同时也更利于开发者维护代码。

• 补充：

其实我觉得学习promise的简单使用的成本并不是太高，尤其是跟多层嵌套调用、不利于维护等比起来，真心个人感觉这点学习成本很低。

当然，也不是没有解决办法， 比如可以通过在全局的app.js中增加一个配置项，用来指定是否全局开启异步API的promise调用方式，或者是在单个API中增加一个配置项，来指定当前API是使用原本的异步方式还是使用promise方式。

这只是个人建议，仅供参考。但我真心觉得异步API使用promise肯定会越来越成为更多开发者的呼唤和心声的！