promise知识点以及面试题

Promise 出现的原因

在 Promise 出现以前，我们处理一个异步网络请求，大概是这样：

// 请求 代表 一个异步网络调用。
// 请求结果 代表网络请求的响应。
请求1(function(请求结果1){
    处理请求结果1
})
复制代码

看起来还不错。
但是，需求变化了，我们需要根据第一个网络请求的结果，再去执行第二个网络请求，代码大概如下：

请求1(function(请求结果1){
    请求2(function(请求结果2){
        处理请求结果2
    })
})
复制代码

看起来也不复杂。
但是。。需求是永无止境的，于是乎出现了如下的代码：

请求1(function(请求结果1){
    请求2(function(请求结果2){
        请求3(function(请求结果3){
            请求4(function(请求结果4){
                请求5(function(请求结果5){
                    请求6(function(请求结果3){
                        ...
                    })
                })
            })
        })
    })
})
复制代码

这回傻眼了。。。 臭名昭著的 回调地狱 现身了。

更糟糕的是，我们基本上还要对每次请求的结果进行一些处理，代码会更加臃肿，在一个团队中，代码 review 以及后续的维护将会是一个很痛苦的过程。

回调地狱带来的负面作用有以下几点：

• 代码臃肿。
• 可读性差。
• 耦合度过高，可维护性差。
• 代码复用性差。
• 容易滋生 bug。
• 只能在回调里处理异常。

出现了问题，自然就会有人去想办法。这时，就有人思考了，能不能用一种更加友好的代码组织方式，解决异步嵌套的问题。

let 请求结果1 = 请求1();
let 请求结果2 = 请求2(请求结果1); 
let 请求结果3 = 请求3(请求结果2); 
let 请求结果4 = 请求2(请求结果3); 
let 请求结果5 = 请求3(请求结果4); 
复制代码

类似上面这种同步的写法。 于是 Promise 规范诞生了，并且在业界有了很多实现来解决回调地狱的痛点。比如业界著名的 Q 和 bluebird，bluebird 甚至号称运行最快的类库。