用了几年的Promise，竟然还搞不清楚返回值是什么～

大家好，我是疯狂的小波，一个热爱分享实战经验的前端开发。

这几天在开发功能时，调用同事写的函数，发现Promise在部分场景下没有手动变更状态。大概长下面这个样子：

于是就产生了下面这样的对话：

然后自己再仔细想想，是啊，没有手动处理不可能默认返回完成状态。Promise 内部状态的变更，大部分都是在异步操作中处理，这样的话，如果没有执行到变更状态的代码时，就已经是完成状态了？显然是不可能的。

正确的应该是没有执行到变更状态代码时，构造函数返回的 Promise 始终是待定状态。

这应该也是大部分人的正确认知。那我为什么会产生这种基础的错误认知？

在此之前我还特意看过 MDN 上 Promise 所有相关的文档，当时自认为对 Promise 已经足够了解了。没想到没过多长时间，一个这么基础的问题瞬间打回原形。

后来仔细想了想，让我产生这种误解的原因，还是理解的不够深刻，当时只是通过死记硬背的方式把文档内容记忆了下来，导致时间长了之后，记忆开始有点混乱了。

“没有手动返回，就返回完成状态的promise，只是值为undefined”，这个是 then、catch 方法，以及 async 函数返回值的其中一个规则，而不是构造函数的。

出了上面这个事情之后，再仔细想想，好像平常在用 Promise 进行开发的时候，有时也会遇到模棱两可或者拿不准的地方；再看看现在项目中的代码，发现也有很多不简洁、或者是使用错误的地方。

比如项目中的这种错误代码 ❌：

还有这种不简洁的代码 😭：

所以就把平常使用过程中存疑的、还有这种使用错误的地方，简单总结了下面几条：

为了解决这些困扰，我把文档又全部重新理了一遍，并且结合demo和Promise的源码，总算把这些问题都搞清楚了。下面把我的解决过程和结论分享出来，如果在使用 Promise 的时候你也有过类似的困扰或其他的问题，相信一定会有所收获的。让我们以后使用 Promise、async/await 时都能够快速、精准的做出判断，再也不被这些问题困扰了 💪💪💪。

在此之前，需要先简单回顾下 Promise 的2个基本内容：Promise状态 以及 Promise() 构造函数。

我们后续的内容，基本都会基于这2个来展开。

除了我们自己通过 Promise() 构造函数创建的 Promise对象 ，通常我们使用一些第三方 API，也会返回一个 Promise对象 (如 axios)。

而 Promise对象 有3种状态。

当由 pending 状态变更为 fulfilled 或 rejected 状态后，不会再变更。

包装不支持 Promise（返回值不是 Promise）的函数，返回一个 Promise对象。常用于处理异步操作可能产生的不同结果。

构造函数执行时，会返回一个 pending 状态的 Promise对象，构造函数包裹的函数会立即执行。在异步执行到 resolve() 时，Promise对象 的状态会变更为 fulfilled 状态；执行 reject() 时，状态会变更为 rejected 状态。

注意：如果没有执行 resolve、reject 函数，则返回的 Promise对象 始终为 pending 状态，后续的 then、catch、finally 回调方法也不会执行。

then()、catch()、finally() 实例方法始终都会返回一个新的 Promise对象。这也是为什么 Promise 能链式调用的根本原因。每次调用实例方法时，都会返回一个 Promise，这个返回值就又可以继续调用实例方法了。

但是不同的实例方法、不同场景下，返回的 Promise 会有区别，这就导致在后续链式调用时，代码执行逻辑也会不一样。所以弄清楚实例方法的返回值至关重要。

这里 then()、catch() 的返回值原则是一致的；finally() 有点区别。

then 方法接受2个参数：onFulfilled 是 Promise对象 变更为 fulfilled 状态的回调；onRejected 是 rejected 状态的回调（可选）。这2个函数都有一个参数，接受状态变更时传递的值。

.catch(onRejected) 等同于 .then(undefined, onRejected)，只是它的一个语法糖，所以在返回值规则上，他们也是相同的。

示例如下：

async 函数的返回值原则，与上面的这些原则是一样的。所以弄清楚这些对我们用好 async/await 也有很大的帮助。

从表现上来看就是直接跳过没有对应状态回调的实例方法。比如调用 Promise.reject().then(onFulfilled) 时，由于 .then 中没有 rejected 状态的回调，.then() 方法会直接返回与 Promise.reject() 相同的 Promise。

示例如下：

上面代码中，当执行 do 1 时返回一个 rejected 状态的 Promise（P1）；执行到第二个 .then 时，由于没有 rejected 状态的回调，这个 .then() 会直接返回与 P1 相同的 Promise，继续执行到 .catch，则会进入 .catch 的回调。从表现上看，中间会直接‘跳过’ do 2。

这也是为什么：我们在链式调用时只在最后写 .catch()，之前的错误都能够捕获到；

同理，当我们希望某个操作不管是完成还是失败，都可以继续走后续的逻辑时，就可以将 .catch 写在指定的 .then 方法后，这样不管这个 .then 是否触发异常，也不会影响后续的链式调用。

通常情况下，Promise 中的这种链式调用使用 async/await 会有更好的体验。

为了进一步加深理解，我们从代码层面来看看，到底 Promise 内部是怎么处理的。

模拟 Promise 源码如下。为了方便理解，基本上每一步都加了注释，我们这里主要关注的是 then 方法的处理，在注释中也标识了上面返回值规则对应的代码处理：

了解了源码之后，再来看之前的代码，是不是会觉得更加清晰了：从 Promise 实例初始化，到状态变更，再到调用 .then 方法的内部处理，以及不同状态下实例方法的返回值，最终根据这个返回值是怎么完成的链式调用。

可以再结合源码来看看下面这段代码：

怎么样，如果结合源码的执行来看，是不是整体的感觉比之前更清晰了。我自己是感觉对 Promise 的掌握又更上一层楼了，至少不会在短时间内再忘记了～。你也点赞收藏下呗，免得时间长了之后忘记又找不到啦😊～

啥？为啥会抛出异常？看到这里了都不点个赞，不得出异常吗～

.then 和 .catch 的使用在日常生活中非常多，所以分享的内容会多一点。下面我们再来看看另外一个实例方法 .finally() 。

在 Promise 结束后，无论结果是 fulfilled 或 rejected，都会执行 onFinally 回调函数。与 .then、.catch 不同的是，onFinally 回调函数没有参数。返回值也有所不同：

返回与调用该方法的 Promise对象 相同的 新Promise对象。

与上面的 then、catch 中第2条规则：没有对应状态的回调函数时，返回原则是一样的。有点区别的是：如果在 onFinally 回调中，抛出异常或返回 rejected 的 Promise，则 .finally() 会返回这个 rejected 的 Promise，不过通常情况下并不会这样使用。

Promise 基于 then()、catch()、finally() 实例方法返回一个 Promise对象，达到了可以链式调用的效果。只要我们掌握这些不同场景下不同的返回值，对于 Promise 的链式调用，就可以很清楚的知道执行逻辑了。有些其他的框架也有这种设计思路，比如 Jquery 的实例方法，就是返回的 Jquery实例对象，也是可以很方便的进行链式调用。

现在再看看刚开始总结的第1、2个疑问：

是不是现在感觉非常清晰了~，如果还有疑问，可以在评论区与我交流哦～。

顺便也可以想想第3个问题：3..catch() 与 .catch(() => {}) 对异常处理区别是什么？如果对上面的返回值规则理解了的话，应该就能发现区别了。

没有发现也没有关系，下面介绍异常处理时，我们再来揭晓这个答案。

当链式调用的链路比较长时，一般会使用 async 和 await 关键字来实现，代码会更清晰和简洁。

类似下面这样：

async/await 中使用 try/catch 进行异常捕获，与 then/catch 类似。可以像上例中，统一进行捕获，这种中间任一个函数抛出异常或 rejected，就会跳转到 catch 中执行。与 then/catch 中，最后一个 .catch 可以捕获前面所有异常效果是一样的。

使用 async 时，其中一个容易出错的也是函数的返回值。特别是嵌套调用等复杂场景，如果不能明确每一步的返回值，就容易产生很多问题。

始终返回一个新的 Promise对象。

1、与 then()、catch() 的返回值规则相同。如果 async 函数：

示例如下：

2、await 等待的函数 抛出异常或返回 rejected 的 Promise 时。

没有异常捕获：则后续代码不会执行， async 函数直接返回 rejected 的 Promise，值为抛出的异常值或 rejected 值。

内部有异常捕获时：异常时，控制器执行 catch 块代码，再根据上面的第1条规则返回

整体上来说，和 then()、catch() 的返回值规则是差不多的。

有时 async 函数会直接返回一个值，如果习惯性的直接使用这个返回值，就会出错。

由于 async 函数的返回值是 Promise， 所以获取返回值时也需要通过 Promise 的方式来获取。

或者再次使用 async/await 获取，这也是为什么通常说 async 函数具有传染性的原因。

另外一个容易产生误区的地方就是 return await 和单独 return，经常在使用过程中发现2者都有使用，但是感觉效果又是一样的。下面我们就来看看他们到底有什么区别。

如下，当 doSomething() 抛出异常或返回 rejected 时：

return await doSomething()，将等待 doSomething() 执行出结果 (fulfilled 或 rejected)，如果是 rejected，将会在返回前抛出异常。

而直接 return doSomething()，不管 doSomething() 返回的 Promise 是 fulfilled 还是 rejected 都将会直接返回这个 Promise 本身

像这个例子中，如果中间没有其他的 await 关键字，使用 async/await 就很多余了，就像最开始的例子中一样。可以直接写成普通函数就行。 function foo() { // do something; return doSomething(); }

如果像上面举例这样记忆，就显得太复杂了，显然这不是一个好的方法。

其实我们只需要知道一点：await 关键字是获取 Promise 的 fulfilled 状态的值，如果 Promise 是 rejected 状态，则会直接抛出异常。

基于这个原则，再来看上面的例子，其他的代码都很熟悉，是不是能得到相同的结果。这个才是根本原因，上面的场景只是由这个原因导致的结果。

我们现在再来想想上面提的第4、5个疑问：

如果能够立马想到答案，那说明对上面的内容基本上掌握啦 😄～

既然已经说了这么多 async 的内容，再分享一个最近发现的一般人不会注意的小技巧。

常规的处理多个异步操作时，如果有依赖上一步的数据，通常都是链式调用。就像我们上面的例子中一样，等待上一个调用完成后，再进行处理下一个。

而有些场景下，异步操作在调用时没有依赖，但是在处理上有顺序要求。比如商品详情页2个接口，获取商品详情信息、获取当前页面配置的促销信息，调用时没有数据依赖，但是只有当商品获取成功时才展示促销信息。此时接口调用就可以同步开始获取，进行异步处理，这样可以更快的让页面呈现出完整数据。如下：

2种方式最终实现的效果相同，第1种方式页面完整呈现时间是2个接口请求时间相加，而第2种方式是最长的一个接口请求时间。在某些场景下还是比较有用的，需要的话快使用试试吧～。

还记得我们上面提到的这个疑问吧：.catch() 与 .catch(() => {}) 对异常处理区别是什么？

在日常开发中经常看到这种 Uncaught (in promise) 错误，不管是我们自己写得代码，或者是第三方的代码，可能都会抛出这样的异常。就是当 Promise 变更为 rejected 时，没有被 catch 方法捕获到。

比如下面这样：

当 doSomething() 返回 rejected 状态时，由于没有 .catch 方法捕获异常，就会直接在控制台中抛出错误 Uncaught (in promise)。

所以通常都要在链条最后加一个 .catch 来处理这种异常。

有时为了避免抛出异常，或者不管 Promise 是完成还是失败时都继续向下执行，但是又没有其他的业务处理时，我们会简单的加一个空的 .catch() 。

这样写并不会捕获到异常。还记得上面的返回值规则吗？ .then()、.catch() 的返回值是根据内部对应状态的回调函数决定的，单纯的 .catch() 没有回调函数，就会匹配其第2条原则：没有对应状态的回调函数，那就会返回一个 与调用该方法的 Promise对象 相同的 新 Promise 对象，所以这里当 doSomething() 返回 rejected 时，.catch() 后还是会返回 rejected 的 Promise。所以最终还是抛出了 Uncaught (in promise) 错误。

那如果我们不希望每一个地方都去单独捕获，或者第三方内部的代码抛出这种错误，我们没有办法直接捕获的时候，应该怎么办？

可以通过 unhandledrejection 方法来全局捕获这种错误，然后在监听事件中做些自己的处理，比如需要做自定义的异常监控或问题收集时。

到了这里，我们开始时提出的几个疑问，基本都能找到答案了。

这一章想单独介绍下 链式调用中的异步性，也就是代码的执行时机（promise在事件循环机制中的简单表现），感兴趣的也可以看看。

除了链式调用时的返回值，如果不清楚回调函数的执行时机，有时也会遇到各种问题。

promise 中的回调函数执行遵循以下3条基本原则：

如下，我们有主函数执行语句，主函数中的定时器，以及 Promise 的 then 回调。根据上面的原则，then 回调是异步调用，setTimeout 也是异步调用，并且优先级低于 then 回调。最终的执行顺序如下：

上面的代码中，只有单一的 then 处理，如果是链式调用，执行顺序是什么样的？

在第一个示例的基础上，我们添加了多个 then 的链式调用。如果上一个 then 返回的是一个 fulfilled 或 rejected 状态的 Promise，则后续 then 的回调会继续执行；如果返回的是 pending 状态的 Promise，则会等 Promise 的状态变更为 fulfilled 或 rejected，再异步执行对应状态的回调。

还记得上面的 Promise 源码吗？如果结合源码再来看看这里的代码执行时机，这些文字描述，是不是变的更好理解了？

扯了这么多，终于把开始提出的6个疑问搞清楚了～。不过你确定真的都掌握了吗？会不会过一段时间像我一样又忘了，所以点个赞收藏一下呗～，记住不迷路。如果还有疑问或者有其他的问题，也欢迎评论留言与我交流 🎉🎉🎉。