async await 的 实质 就是 用 “状态机” 来 取代 函数层层调用 。
async await 的 本质 是 语法糖， 和 提高性能 什么的 没什么关系 。
为了避免理解歧义， 我把 “状态机” 称为 “控制机” 。
为了实现一个 语言级 的 ， 在 任意代码 中 通用的 异步回调 “变成 同步代码” 的 语法糖， 需要 解决 函数层层调用 的 问题， 即 异步调用 包含在 函数层层调用 中的问题 。
为了解决这个问题， async await 通过 编译器 对 代码 进行了 切割 和 重新整理， 再拼凑起来， 还原出 原本的 代码 执行的效果 。
还原， 就是用 “控制机” 来 对 切割成 “步骤” 的 代码 逐步调用， 所以， 原本代码中的 函数层层调用 被 控制机 取代了 。
而 async await 的 性能 相比 普通方法 并没有 提高， 相反还 降低 了 。
可以参考 《后线程时代 的 应用程序 架构》 https://www.cnblogs.com/KSongKing/p/10228842.html
里面有 async await 和 普通方法 的 性能测试 对比 。
不过经过后来的研究， 发现 async await 是良性的， 参考 《无阻塞 编程模型》 https://www.cnblogs.com/KSongKing/p/10287882.html 。
在 QQ 群的讨论中， 有 网友 给出了 一段 代码 ：
通过 这种 方式 可以 以 回调 的 方式 把 每层 方法里的 await 后面的代码 层层 打包 返回 到 最上层，
然后再 UnWrap() ， 即 层层 执行 await 后面的代码， 如下图 ：
通过 闭包 把 await 后面的代码 变成一个 函数， 再把 这个 函数 作为 回调 通过 上述 的 方式 层层打包， 等 异步方法 执行完后 又 层层执行 这些 回调， 这样可以实现 async await 的效果 。
也就是说， 编译器 按 上述方式 处理 代码 的话， 可以实现 async await 。
用这种方式的话， 可以不需要 控制机 。
这个 网友 认为 状态机 是用来 处理 多个 await 的 场景 的 ：
不过 后来 他又说了 “状态机只是一种优化， 不是必须的” 。
而 另外一位网友 说 “状态机 是为了减少闭包上下文传递” 。
So ……
So …… ？
So ？