终极建议，不要用nodejs。nodejs的异步模式非常初级，粗暴，简单，不利于和谐，异步终极的目标是没有异步，没有显式异步的异步才是好异步。

没有显式异步的异步其实就是同步，如果你觉得nodejs的异步模式不好理解，那么可以试一试fibjs的形式同步。

曾经我对nodejs的异步模式深信不移，后来才发现，什么回调，什么promise，什么generator都特么弱爆了，有这个时间去搞这些，还不如coroutine来的清爽实在，协程才是异步的未来，才是将异步代码转为同步代码的正途。大牛们告诉我们，这个世界是并行的，这个世界是异步的，并行，异步才是符合人类思维模式的。但请注意这个观点仅仅适用于大牛。我不属于大牛，我脑子比较简单，我的思维方式是顺序是同步的，我怕耗费无谓的时间在流程控制上，怕花时间在理解generator上，所以我选择形式同步，抛弃了nodejs。

nodejs不改变，不管它版本号变得怎么快（刚出了4.0，立马跑去看，这样的更新能搞一个大版本号？难不成这个版本号是庆祝社区合并？），都不能代表未来，因为我坚信，这个世界普通人还是大多数，大牛毕竟是少数。

如果不像抛弃nodejs，请把回调模式下的异步彻底搞明白了再来写代码，不然死多活少。教你一个理解回调模式下的异步的秘诀，你必须要搞清楚，所有javascript的代码除了回调函数外都是同步执行的，所有带回调的函数只是发出异步命令和注册回调函数，命令发布完毕，就会顺序往下执行，异步命令执行完成之后，调用回调函数。回调函数调用是异步的，但一旦被调用，除非某异步函数发出另一个异步命令，否则回调函数内都是同步执行的。回调函数的作用其实就是保证逻辑顺序，是为了保证同步，从这点上来看，那些宣称世界是并行的异步的大牛其实都是骗子，我们的脑子事实上还没那么发达，我们的思考模式其实还是顺序的，是同步的。回调模式只是比多线程的锁同步要好理解得多，仅此而已（当然性能上也是好得多）。

	var fs = require('fs');
	var a = 0;
	fs.readFile('test.txt',  'utf-8', function(err, data){
		a++;
		console.log('a in:' + a);
	});
	a++;
	console.log('a out:' + a);

下面是我用lua协程的实现，假设代码已被包含在某个协程中。

	local fs = require('fs')
	local a = 0
	data,  err = fs.readFile('test.ext',  'utf-8')
	a = a + 1
	print(a)

fs.readFile实实在在是异步的，基本的原理就是发出异步请求之后将当前协程挂起yield，异步请求完成后将结果resume。 当然在这么简单的运用看不出谁好谁坏的，当有层层回调的时候，协程的威力才会显现出来，一个要时刻考虑回调的执行顺序，参数传递，错误处理等问题，一个就跟写同步代码一样。

@fengmk2

写你这样的代码，如果只是作为普通用户，不需要理解原理，照着做就行了，如果稍微有点追求的，要探求个所以然来，这就要下功夫了。首先必须要透彻了理解回调模式下的异步，因为这些代码背后首先做的就是对回调的包装和转换，这个转换本身理解成本就不小，为什么要这么转换，理解generator是如何将回调异步转为形式同步的成本也不小，这中间就造成了大神与普通用户的区别，当然有的人是醉心于这种不平等的。而我的方案是平的，不需要附加任何额外的代价，不需要死额外的脑细胞，但对眼里只有javascript一种语言的人是无解的。

这里还有人说lua是很low的语言，我只能表示无语，一个优美小巧的学院派语言竟然被称为low，lua和javascript我都很喜欢，但javascript是工程应用的产物，是很多无奈的妥协的产物，虽然很成功，但却是远不及lua简单干净的。

形式同步大家已没有争议，这是大势所趋，javascript也在朝这个方向发展，但历史包袱过重，进化得过于缓慢，协程的引入也搞成了半调子，es6既然已经这样，下个版本干脆直接一步到位得了，回调异步转形式同步，协程是绕不过去的，不管表面上用什么关键字，yield也好，await也罢，都要在异步的时候主动让出CPU，让其他协程来继续。

已经习惯了回调异步的同学，建议你们立即向形式同步转吧，这个趋势不会因为自己已经习惯了而改变，你不改变就会被淘汰。永远要记住，我们要的是异步带来的好处，而不是复杂难懂的异步代码。

@dayuoba

这个打印的就是文件内容

@wenshiqi0

go的模型比javascirpt的要好。

异步本身不难理解，难的是复杂的逻辑和错误处理，回调模式下的异步这个问题是很头疼的。

co如果仅仅是应用，不需要理解原理， 那的确没什么难的，但能把回调模式下的异步转成形式同步的原理完全搞明白了还是要废点脑子的。田永强的这篇文章不错http://www.infoq.com/cn/articles/generator-and-asynchronous-programming/

我的方法是不需要做这么多转换的，lua天生支持协程，所有的包装在c层面做好了，在lua层面就是同步代码，完全不需要进行任何转换。c层面也很容易理解，我的做法跟openresty是一样的。

@wenshiqi0

为什么要实现协程？在javascript里么？javascirpt不是已经提供了generator这个半调子协程了么？

generator里的yield就相当于lua的yield，next相当于resume。

@wenshiqi0

c实现协程主要有两种方式，一种是是lua用的longjmp，还有一种是ucontext，fibjs就是自己用汇编实现的ucontext（为了兼容windows平台）

@wenshiqi0

我也喜欢弄新东西，折腾自己，这样不管结果如何，自我提升还是很快的，做http库的话可以交流啊。

@dayuoba

当然是异步的，如果是同步的话就没有意义了。readFile调用的同时当前运行的协程会让出CPU给其他协程运行，等readFile异步运行完成后，会将结果压入协程堆栈，协程唤醒继续向下执行。

es6的generator可以模拟这个过程，首先要将原来的异步函数都包装成一个可以传入真实回调函数的函数，

	  function readFile(file, options){
	  	var pass;
		
		fs.readFile(file, options, function(err, data){
			if(pass){
				pass(err, data);
			}
		})
	
	   	return function (fn){
			pass = fn;
		};
	}

再通过generator.next()来触发执行异步函数，这个过程只是巧妙的利用generator的特性伪装了回调，其实整个异步过程还是通过回调函数来控制的。generator用这种方法只是伪装了协程特点，但不能算是协程，还是主要利用回调来实现的。当然javascript有javascript的难处，船大难掉头，他必须兼容之前的回调代码。

我用lua实现的是不需要兜这么大圈子的，直接了当当成同步函数用就行了，我们只是要异步带来的好处，还管什么异步的形式？只要能痛快的写代码就行了。

@tim1020

nodejs开了个好头，但能不能笑到最后就要看后续的发展了，nodejs是成也javascript败也javascript，javascript编程模型在接下来几个版本可能会剧烈变动，人心如果散了，队伍就不好带了。。。

我对nodejs的评价是，可以学思想，但千万不能被他的形式束缚。nodejs最初的作者那么激烈的反对协程，认为回调才是异步的未来，现在大家被回调折磨几年之后，其实都在思变，不管是generator还是async，显式的异步终将慢慢退出舞台，后面的历史必然会由形式同步来书写。

我们要的是异步的好处，而不是复杂难懂的异步代码。

@kiliwak

我不是极力推荐lua，我选择语言是很现实的，自己熟悉，能够解决问题，lua天生就提供了异步转同步的基础设施，很多人也做了很多探索，有可以参考的代码，lua可以很轻松的做到形式同步，实质异步。很多人对lua有误解，没有深入的了解，其实lua和javascript是非常类似的，语法虽然不是类c的，但核心的东西都是可以类比的，熟悉javascript的人可以很快上手。

lua与c绑定接口比较简单，我有大量的计算要做，这部分原来用javascript写的，node运行会有明显的阻塞，严重的会客户端假死，超时。用c改写后好很多，v8很快，那是跟其他脚本语言比，跟原生的还是有很大差距的，尤其是数学计算。v8的绑定还是稍麻烦，没有lua这么清爽简单。lua这个特性对库的增加是非常有利的，像node-canvas这些库，都可以移植成lua版本的。

如果有一天javscript也提供了像lua一样的异步转同步的基础设施，我可能还会转到node，但现阶段，javascript语言进化不确定性太多了，这两三年内版本估计变动得可能比较剧烈，我认为lua更符合我现在的需求。

很多人其实并没有真正的理解异步，也没有理解异步回调的意义，就觉得用异步了，性能就提升了，好牛逼的。很多人还在大谈人的思维方式，异步符合人类思维方式云云，都是自欺欺人，人类的思维方式要真是异步，还要层层回调做什么？回调干的就是同步的活，就是保证执行顺序的，一边被回调折磨的很爽，一边自我安慰说这才是异步的正途，但讽刺的是，回调特么就是为了保证同步的。人就是顺序思维的。

你的方案我看过了，还是比较复杂的，刚上手的话必须要有个学习适应的过程，这其实就是javascript无奈的地方，必须要兼容原有的回调代码。我追求的是完全没有异步的异步，没有协程的显式创建（每个链接就是一个协程，所有异步操作都围绕这个协程进行切换），没有协程的显式运行，没有yield，没有resume，这些都是在c层面对用户隐式调用的，用户看到的代码就是简单的同步代码，用户只要熟悉下文档，没有异步基础也能堆代码。我的方案跟openresty类似，openresty与nginx结合的过于紧密，我选择的是lua+libuv组合，linuv是非常优秀的异步库，libuv可以说是nodejs的核心，理解了libuv，就基本理解了nodejs，这样的话，我将来如果要转回nodejs也是很容易的。

@kiliwak

每个request一个协程代价是否大了点，我认为每个连接一个协程可能更好，不过nodejs可能要动到底层库。

这也是nodejs无奈的地方，从一开始就排斥了协程，现在其实又要回头，不管是es6的generator还是es7的await都是类似协程方式实现的。要想从回调异步转为形式同步，协程是绕不过去的，nodejs必须要兼容回调代码，这个时候，很多人引以为傲库的数量反而是个累赘。转换完成后的同步代码大家都会写，但最关键的就是如何转换。举个例子，如果用户不明白到底是如何转换的，不明白整个框架，转换或框架过程出了任何问题，用户就束手无策了，这中间就有了所谓高手和普通人的区别，其实这种区别完全是没有必要的。generator和你的方案都是存在这种问题的，很多人都觉得没必要理解，会用就行，但我认为，如果不能理解的话，整个数据的流向不清晰，碰到问题，极有可能要吃亏的。再者稍微有点追求的程序员，都不会让自己做一个白痴，都会对自己的使用技术的原理探个明白。

在大方向上，其实大家已经很明白了，回调必死（之前还有人跟我争论，我反问了一句，既然回调那么好，那要pormise和generator做什么？什么东西，有缺陷就是有缺陷，回调异步老早就有了，为什么没有大规模使用，就是用起来麻烦，在c里写个两层以上就恶心的不行了。），但就是具体的技术实现上，我个人追求的比较极端，我追求完全没有显式异步的异步，我也追求极致的性能，所以现阶段，javascript对我而言肯定不是好的选择。