能和微博上的 @盗贼 （fibjs作者）掰扯这个题目是我的幸运。
事变缘起于知乎上的一个热贴，诸神都宣布了看法：
https://www.zhihu.com/questio…
这一篇不是要说邃晓什么是async/await，而是论述为何会在编程技术这么多年后涌现和盛行了这个东西，读懂这篇文章你须要对async/await有很透辟的机制明白。
假如是写体系递次，盛行的编程范式是面向对象，这异常成熟不必多说；但假如是写微效劳(restful api server)，状况差别。
写微效劳的时刻数据不是从文件或数据库读取、去串行化、组织对象然后在内存中保护对象；而是向数据库、cache、或许API提取数据，盘算后尽快输出效果；
前者的数据对象生命周期较长，object-oriented范式很适宜，它研讨一个对象的状态机和怎样相应外部事宜；
后者的数据生命周期很短，而且更蹩脚的，种种input数据的构造也不很稳固，常常变化，所以这个时刻OO的形式就显得笨重和低效了，在这个时刻对data的处置惩罚不是object-oriented范式，而是transformation-oriented范式。
后者致使了函数式编程的鼓起，这里没法细致议论函数式编程的各个方面，我们仅仅说transformation的题目。
这类编程范式下一次api效劳的生命周期在心思模子上一个函数的最先和完毕，这个函数须要从许多处所pull数据，假如是从内存中直接pull，这个在fp里叫做state monad；假如是异步pull数据，包含文件、数据库、其他api，这个叫io monad。
OO的实质站在fp的角度看是怎样保护state monad，假如递次中有stateful的部份，或多或少都邑有，用oo建模不是题目；接见这些state都是同步的也不是题目；
async/await的涌现是为了处理第二个题目，io monad。
在采纳transformation和fp体式格局写微效劳的时刻，罕见状况不是处置惩罚单一数据单位，而是数据鸠合，鸠合数据的变动是map/filter，聚合是reduce（广义）；这个历程能够有条件，能够是nested，其构造取决于你的营业逻辑和solution model，不是编程技术处理的。
所以你大致能够把这些逻辑先用同步的体式格局写出来，假定统统异步取得的数据都能够同步取得，然后把须要pull的数据改成用async/await去猎取；这在构造上很清楚；
在这个时刻开辟者斟酌的题目不是怎样应付单一数据的异步猎取题目，而是斟酌这些异步历程之间怎样去串行和并发的题目；换句话说，他们的实行序是你要program的逻辑的一部份。既然他们是programming逻辑的一部份，那末他们显现存在就理所应当。
这里说的串行和并发仅指从io monad里pull数据的操纵，不是指递次中其他部份的实行体之间的并发或并行。下同。
这里有两个均衡：
第一：假如要寻求service time越短越好，也就是进步相应时候，那末这些异步就会象project软件里的甘特图一样，能并发的尽早并发，service time取决于最长的途径。一般瓶颈都是io不是算力，除非设想有题目或许算法写得太烂。
这类优化极可能带来代码构造的不清楚，然则它是能够做而且轻易做的，在async/await形式下，由于它在代码层面上基本上保留了这个甘特图关联。
它顺应营业变化的才能也很好，在营业逻辑变化必需修正的时刻，开辟者总有一个比较消灭的甘特图，假如你不在async子函数里封装太长的不必要逻辑的话；和OO建模时我们重复问一个对象是否是single responsibility一样，一个async函数的封装越原子化，越轻易让开辟者在上层组合递次和并发。
这里我不去批评thread或许fiber或许goroutine或许coroutine的模子，只强调异步数据的pull逻辑的原子化，这是高并发微效劳编程对开辟者提出来的新题目，原则上任何一种开辟语言和开辟模子都能够做到对等的机能和可用性，但实践上大多数状况下，递次员不把program异步pull数据的递次和并发当做是本身编程逻辑的一部份，去享用thread model下的编程逻辑简朴，这是不对的；你能够有理由不急着去做service time优化，然则不意味着你基础不知道它的模子逻辑和假如要去优化，做法是什么。
第二：async函数对gc的压力很大，由于compiler很难去推断在运行时哪些域内变量能够接纳，这差别于闭包变量，闭包变量的生命周期推断在源码级的词法域就能够分析出来；所以async函数的实行应当是短生命周期的。
例子
贴一小段代码，现实项目代码，没什么迥殊的，Promise用了bluebird库：
async storeDirAsync(dir) {
let entries = await fs.readdirAsync(dir)
let treeEntries = await Promise
.map(entries, async entry => {
let entryPath = path.join(dir, entry)
let stat = await fs.lstatAync(entryPath)
if (stat.isDirectory())
return ['tree', entry, await this.storeDirAsync(entryPath)]
if (stat.isFile())
return ['blob', entry, await this.storeFileAsync(entryPath)]
return null
})
.filter(treeEntry => !!treeEntry)
return await this.storeObject(treeEntries)
}这是一个class要领。
它的第一步是猎取了一个文件夹内的entries，然后用Bluebird库供应的map要领应用了一个async函数上去，这是个匿名函数。
匿名函数是我们喜好fp的一个重要原因，functor chaining也是，它们离别消除了许多代码细节上须要定名变量名或函数名的须要。
这个匿名函数内，有更多的await操纵，依据fs.stat的效果针对目次和文件做了差别处置惩罚，而且有递归。async以内是递次实行的，但async在map里是并发的，这些东西都显式摆在代码层面上。
假如使命局限更大，你能够把许多promise聚合在尽量早的时刻并发。
固然这个写法没有美好到能够直接写entries.mapAsync()的水平，但基本上做到了上述的请求：在源码层面上对递次和并发有一览，有掌握，轻易变动。
说到底，async是让这类递次和并发的誊写和保护变得轻易，而不是说我不要写并发，统统递次走；然则反过来讲它的效力不是最好的，在node里最好的效力现在和可见的将来都是裸写callback，那是末了的机能优化了。
末了我们说这个写法的一个有点贫苦的坑。
在class要领里写async有个this binding的题目，搞出来一个闭包变量并非最好的方法，Bluebird库里有Promise.bind要领处理这个题目，上述代码顶用arrow function的lexical scope bind this也是一个方法(也是引荐的方法)。
总结
node.js是我写过的最好的地道event model模子的开辟环境；远好过生成thread模子倒回来打许多non-blocking补丁的做法；
javascript范畴，和现在全部编程界，在运用asynchronous(异步)这个词来讲我们在这篇文章里聊的题目，这是个毛病，asynchronous在编程上有其他寄义，无论是写体系递次(signal handler)照样写内核或许裸金属(isr)；这个题目的正确表述是：non-blocking。
而对应non-blocking的solution模子是怎样调理(schedule)实行体；再然后的题目转换成你须要显式调理照样隐式调理？
假如你以为：
service time是须要寻求的
调理逻辑是常常跟着营业逻辑变化而变化的
完全的数据流变动逻辑和调理逻辑都应当在代码层面上显现总览，是top-down的构建的
你应当挑选async/await；
反之，你愿望编程极致简朴，调理不在你的solution模子以内，你bottom-up构建逻辑，应当阔别javascript，挑选thread模子。
白洁
“请把你的左手放在本身的大咪咪上，回复一个题目，调理实行体和调理io是一回事吗？”
白洁摇摇头。
“我也以为不是，然则许多runtime library并没有辨别二者。” said I.
JavaScript的event model并没有所谓的调理实行体的设想，它实质上只要调理io。
