有没有把 Promise, Generator, 和 async/await 之间的关系讲解得比较清楚条理的文章或者博客？

[yazoox]

如果，正在学习前端开发。对这几块有点迷糊。

感觉好像是 先有 Promise, 再有 generator，然后现在又有了 async/await

好像越来越“先进”和“简单”。

有没有对这三者的理解 /解析比较好的文章或者博客，想理解得更深入一些？

谢谢！

[ysc3839]

@woodensail 而且不对呀，这是针对一个 Promise 的情况，假如第一个 Promise 执行成功了，要执行另一个 Promise，还是会变成那种回调嵌套的情况。

[woodensail]

@ysc3839 是的啊，我上面也说了，promise 在解决回调地狱后也带来了作用域分裂，流程控制困难等新的问题，不是个完美的解决方案。直到 generator 诞生才彻底解决了问题。

[woodensail]

@ysc3839 你看我写的，then 是可以链式调用的，fun1().then(fun2).then(fun3).then(fun4).then(fun5)
只额外包了一层而已。
不会出现回调地狱那样左边 tab 半个屏幕的情况。

[woodensail]

@ysc3839 @ysc3839 接上面那个例子说下 promise 解决回调地狱后带来的新问题。

1：作用域分裂，比如 fun3 中请求的得到的结果在 fun4 要使用，但是直接在 fun3 和 4 的作用域不是同一个。所以直接在 fun3 中定义变量无效，必须把变量声明提前到 fun1 执行之前。

2：流程控制困难，比如 fun2 中请求结果显示流程不能继续执行，需要退出。
这时候没法跳过 345 的执行，要么 fun2 通过变量或返回值来通知，在 345 的开头分别判断一下标志，有标志就直接退出。
或者直接抛异常来跳过后面的步骤，但这样一样，业务流程就和真正的异常混在了一起，给异常治理带来了麻烦。

[ysc3839]

@woodensail 查了下文档，是我孤陋寡闻了。then 的回调函数可以返回一个 Promise，下一个 then 的回调就会在返回的那个 Promise 完成时被调用了。

[woodensail]

@ysc3839 嗯，我当年刚知道 promise 这个特性的时候非常兴奋，然后很快就被业务教做人了。
一个医保的业务，需要
1：访问自家服务器获取订单信息(包含多个账单)
2：访问医保服务器做预结算
4：循环访问医保服务器，一个一个创建账单
3：访问自家服务器记录账单
5：循环访问医保服务器，一个一个确认账单
5：访问自家服务记录结果
其中任何一步失败都要跳过后续步骤，并且记录失败信息。如果失败时已经有部分账单被创建需要进行取消；如果有部分账单已经确认，需要进行退费。

最后用皮肉面色写出来一坨屎山，太绝望了，过去这么多年，我都再也没碰到过这大的屎山了

[yazoox]

@woodensail 兄弟，既然你觉得 Promise 不能很好处理这个“医保”问题。
时隔多年，现在有了 async/await 了，能否很漂亮的解决当年的这个问题呢？

我觉得这个问题很值得花点时间研究一下。

如果你有空的话，可能分享给我们大家。（别忘记了 @我一下）

[woodensail]

@yazoox 后来有想过，不过已经跳槽了也就不管了。如果用 async 的话有几个优势，首先整个流程在同一个方法中，可以随时 return 退出后续步骤，在扫尾处理方面会简单很多。
另外由于 async 中可以直接 for 循环执行异步语句，所以不需要用 promise 迭代的方式来顺序执行数组中的任务，也让代码可读性大幅提高。

整体的话估计开发难度不到原来的一半，代码量下降不多但是可读性大幅提升。