原文地点：http://zodiacg.net/2015/08/javascript-async-control-flow/
跟着ES6规范逐步成熟，应用Promise和Generator处置惩罚回调地狱题目的话题一向很热点。然则对处置惩罚流程控制/回调地狱题目的种种东西熟悉依旧比较贫苦。近来两天看了许多文章，想出几个场景把种种异步流程体式格局类比一下，希望能有助于明白他们的完成。
须要申明的是类比只能反应被类比的事物的一个方面，必定有其反应不到的部份，不能完整以类比来明白种种异步控制的实质。所以仅用于简化明白，疾速入门，依旧须要浏览有深切研究的文章来加深对种种异步流程控制的要领的控制。
文章中没有严厉运用Node.js中心模块的函数名，而是捏造的函数名来方便在种种体式格局下坚持一致性和简化誊写。
同步
从最简朴的同步最先。以一段典范的代码为例吧，传入文件名，从文件中读取内容并按JSON花样剖析，把个中的一部份内容发还给用户。
function foo(filename){
var file = readFile(filename);
var json = parseJSON(file);
return json.someContent;
}
var resultA=foo('first.json');
var resultB=foo('second.json');个中readFile和parseJSON不言而喻是同步、壅塞的函数。
我们组织如许一个场景，M(ain)代表着诠释引擎的主线程，坐在柜台前守候用户提交要求。
来了两个用户A和用户B，用户A排在前面。
用户A: 你好，我要读文件
first.json。
M：好的你等一下我去拿。
【M离开了柜台去拿文件】
M：好的我返来了，这是你要的first.json的内容。然后呢？
用户A：然后把内容按JSON剖析一下。
M：你等等我去剖析一下。
【M离开了柜台去剖析文件内容】
M：好了剖析完了，然后呢？
用户A：我要内里的someContent部份。
M：给你。再会。用户B：你好，我要读文件
second.json。
…………
可以看到同步壅塞望文生义，操纵一步一步举行，碰到IO操纵每一步都要守候，用户A不处置惩罚完，用户B也进不来。
典范回调体式格局
依旧是这个需求，此次的代码就比较像Node.js里的罕见情势了，此处为了简朴疏忽了err。因为回调套回调，缩进犹如金字塔，被称作回调地狱。固然回调地狱远不是一个缩进金字塔那末简朴。
function foo(filename, cb){
readFile(filename,function(file){
parseJSON(file,function(json){
cb(json.someContent);
});
});
}
foo('first.json',cbA);
foo('second.json',cbB);依旧是来了两个用户A和用户B
用户A：你好，我要读文件
first.json，按JSON剖析后把内里的someContent寄往cbA发还给我。
M：好的。
【M最先写信，信封上写上文件读取处readFile，拿出一张信纸写到：“读取first.json，然后内容放进后附信封中寄出”。】
【M又拿出一个信封，写上JSON剖析处parseJSON，信纸上写到“把给你的file按JSON剖析，然后把内里的someContent放到所附信封里寄出”。】
【M又又拿出一个信封，写上cbA，然后把这个信封放进了适才的信封里，又把适才的信封塞进了第一个信封里。】
【M把鼓鼓囊囊的信封扔到邮箱里就不管了】
M：下一名！
用户B：你好……
写几封信的时候比本身跑出去取文件要快的多。异步操纵带来的处置惩罚速率提拔是不言而喻的。
然则为了保证业务流程的连接，信内里就包含了后续统统须要举行的操纵，层层包裹。第一封信寄出，M就既无从得知信走到了那边，也无法控制readFile和parseJSON是否是如本身所想寄出了给他的信封，有无擅自复印了多寄了一两封。
这才是回调地狱真正风险的处所，缺少控制。
Promise
引入Promise以后，许多人就认为能处置惩罚回调地狱了，实在不然。在某些场景下只是让缩进悦目了一点罢了。有些场景下缩进也没法悦目，须要誊写的回调不仅不会削减还会增加。
function foo(filename,cb){
readFile(filename)
.then(parseJSON(file))
.then(function(json){
cb(json.someContent)});
}
foo('first.json',cbA);
foo('second.json',cbB);固然这内里的readFile和parseJSON已是Promise化了的。
依旧是来了两个用户A和用户B
用户A：你好，我要读文件
first.json，按JSON剖析后把内里的someContent寄往cbA发还给我。
M：好的。
【M叫来了一个做事员小P】
M：小P你听好，先去找readFile读取first.json，然后把内容给parseJSON让他剖析一下，末了把剖析的内容里的someContent寄给cb，懂了吗？
P：我做事你宁神！
【小P离开了柜台】
M：下一名！
用户B：你好……
小P是一名M信得过的做事员，M置信他可以挨个去找该找的部门，不偷工减料也不毛手毛脚。让小P去做事比寄一封信靠谱的多，M依旧能很快回过头来继承敷衍下一个用户要求。
固然现实场景中虽然写的时刻.then一会儿连起来写完，并非真的一会儿把内容都交给统一名小P/统一个Promise。更像是一个Promise公司，每一个操纵举行完后都由一名Promise公司的做事员举行下一步操纵。
Promise物如其名，运用Promise主要的就是Promise的可信性，比方Promise的状况不可逆，比方fulfill回调只会被挪用一次。Promise并非逃避誊写回调，而是用一种更牢靠的体式格局来誊写回调。
Co（Generator）
这里只谈co不谈Generator，是因为Generator并非为处置惩罚异步流程控制而生的，而TJ大神用co把Generator和Thunk/Promise连系在一起供应了新的异步流程控制的要领。
var foo=co(function*(filename){
var file = yield readFile(filename);
var json = yield parseJSON(file);
return json.someContent;
});
foo('first.json').then(cbA);
foo('second.json').then(cbB);咦？这代码看起来跟同步的怎样差不多。
此次我们换个要领形貌，一样是来了用户A和用户B，然则先从用户A的视角来看这件事变。
用户A: 你好，我要读文件
first.json。
M：好的你等一下我去拿。
【M离开了柜台】
M：我返来了，这是你要的first.json的内容。然后呢？
用户A：然后把内容按JSON剖析一下。
M：你等等我去剖析一下。
【M离开了柜台】
M：好了剖析完了，然后呢？
用户A：我要内里的someContent部份。
M：给你。再会。
是否是看起来跟同步如出一辙？现实上从M的角度看这件事变呢？
用户A: 你好，我要读文件
first.json。
M：好的你等一下我去拿。
【M离开了柜台】
M：小P来一下！去readFile读first.json，返来叫我。
P：好的我这就去。
【M转向了另一个柜台窗口】
M：你好。
用户B：你好，我要读文件second.json。
…………
…………
P：M，first.json拿返来了。
【M转向第一个柜台】
M：我返来了，这是你要的first.json的内容。然后呢？
用户A：然后把内容按JSON剖析一下。
M：你等等我去剖析一下。
【M离开了柜台】
M：小P来一下！去parseJSON把这堆东西剖析一下，返来叫我。
P：好的我这就去。
【M转向了另一个柜台窗口】
…………
…………
水落石出了，M并没有亲身去拿文件剖析JSON，而是叫来了怨天尤人的小P干活，本身在用户A眼前伪装成被占用了一切的时候的模样，实在偷偷去招待别的用户了。
应用Generator可以用yield中缀实行，再在外部经由过程next叫醒继承实行的特征，co把Generator的next写到Promise的then内里从而完成轮回挪用。运用了co以后，代码看起来跟同步异常相像，写起来相符人一般的同步头脑，以至可以运用同步的流程控制语句比方for。然则实行起来却能充分应用异步带来的机能上风。
趁便提一句，co看起来已异常像async/await体式格局了。Node.js中一样近似于async/await体式格局的另有asyncawait库，它不依靠generator而是依靠于node-fiber，看名字也许就是Node里的一个纤程的完成吧。因为不须要generator，关于诸如Coffescript和Typescript类的言语支撑异常好。
以上就是对Javascript中近来常议论的几种异步流程控制的简朴类比申明。这类明白体式格局异常深刻，而且有许多题目并不像上面写的那样那末简朴。要想运用好异步，照样要多读一些更加深切的文章。
