如题，以前有后台开发经验，最近学了一些NODEJS,也用一些开源项目做了一个简单的站点，个人感觉单从做WEB项目来看的话，NODEJS跟传统的PHP相比，没有感觉出有什么优势，反而因为坑爹的回调，反而开发效率不高，容易出错。目前只觉得用NODEJS，做一个长链接之类的，消息推送什么的还行，做WEB项目，真心没优势啊，各位大神有什么见解？？
- php是世界上最好的语言，但没node效率高
- 坑爹的回调是你不会处理，如果处理好promise/A+，把模型方法和业务逻辑分开,开发效率是非常高的
- node的调试有3种：1node-inspector，2webstorm ide，3tdd/bdd 更多见see https://cnodejs.org/topic/5463f6e872f405c829029f7e
node主要应用场景是在大前端，阿里的思路是比较合适的，但是必须要注意，绝对不能让node做太多的业务逻辑，他只适合接受人家生成好的数据，然后或渲染后，或直接发送到客户端。如果让node做复杂的业务逻辑，那会得不偿失的。这个阿里的人可以来说明一下，你们node主要应用的场景是不是都是比较简单的逻辑。
回调模式下的异步是有明显缺陷的，程序的执行顺序必须依靠回调来保证，没有层层回调，就没有可以保障的逻辑顺序，这也就注定了，node不能做复杂的业务逻辑。javascript语言本身也一直在和回调做斗争，promise，generator都可以将回调包装起来，在代码的某个部分形成形式同步，但是这种模式进化的还不完全，还不能做到与回调完全割裂，做到完全的形式同步。但是形式同步肯定是发展的方向，这种模式即可以获得异步的好处，又可以有效回避回调带来的编程困难，在业务逻辑上可以更简单的表达。
就现在的环境来说，大家的思路还没转过弯，对回调的批评认为都是不好的，这些人是不敢面对现实，javascript都在变，这些人的脑子却不肯变，还以为回调就代表异步。
上面大多数都答非所问，
@coordcn 按你的意思，NODEJS，目前就实际应用中，应该只是做一些简单的功能模块，另外就是做JSON API么？？像JSON 接口这些，直接用JAVA不行么，加一层NODEJS有什么作用，之前看了阿里的博客，根据他们的结构，感觉 加的那一层NODEJS，换成PHP也没什么不同啊，唯一的就是大概前端写JS比PHP顺手？？
@coordcn 非常同意，目前来看node还很稚嫩，api都没有完全确定，callback hell没有完全解决，语法层面更新速度太快，不足以用在大型开发项目中，而且没有提供比较好的拓展包的稳定评级，导致处处入坑的情景，与其把精力放在写出新的代码结构以及为拓展包填坑，不如老老实实的用其他成熟的语言专注业务逻辑。 一句话，现在的node太花哨了。。。
@i5ting 亲，这个图是阿里系的图，我只是借用一下，http://ued.taobao.org/blog/2014/04/full-stack-development-with-nodejs/
天猫这么干，主要出发点可能还在于让前端工程师使用最擅长的javascript负责“全栈”javascript工作来提高团队整体工作效率。至于后端接口，可能都是一些java写的已经稳定的功能，谁也不可能决策再用Node.js去全部改造，因此在Node和java间才有了那一层接口层。这样，用Node.js去实现一层完全配置化的适配HTTP/SOAP/…协议的具有缓存策略的接口路由，再通过配置或少量代码实现接口调用聚合即可完成功能，这些工作前端工程师就能干了，完全不需要后端参与。前后端的交互就在”接口文档”，不需要会议、语言、IM来沟通。
Node.js的业务逻辑应用，阿里的淘宝还是天猫里的收藏功能拒说已经在试水，这次改动应该也是一次大的变动，否则也不会把好好的java改成Node.js。如果阿里得出Node.js在性能和开发效率上超过java、在稳定性上不输java之后，会不会有更多的业务逻辑使用Node.js去实现，这些可能会取决于前后端团队的工作负荷。
Node.js的发展给javascript注入了新的生命力，试想一下，如果你是老板，你是愿意雇佣一个javascript全栈工程师搞定全部前后端工作开他30K，天天让他加班成狗；还是愿意雇佣两个工程师，每人开20K，让他们俩天天有空坐下来撸两把？
至于javascript的垢病，个人感觉，不在它的callback而在它的随意性，随意到想怎么写都行，但正是这点给它带来了惊人的开发效率，做好代码规范和文档工作可以减少javascript的随意性带来的负面影响。
WEB端、移动端、桌面端、甚至嵌入式，javascript已经无处不在。接下来，ES6的实现会让众多习惯同步或者不喜欢回调的开发人员能够更快地上手javascript写出符合他们思维习惯的代码，这些开发人员会是更大的群体，那么也许javascript会横扫应用开发也不一定。
所以，javascript很有前途，那Node.js自然就有前途，有前途就有钱途，你懂的。
实在无法接受php是最好和语言这种论调。我承认它最多人用，但鄙人真心认为它是丑陋不堪的！连它的开发者都承认它是乱凑起来的。没有统一的命名规范，驼峰法和下划线串联命名都有。真是见鬼，最要命的是关联数组的定义，看起来跟函数调用形式差不多！混乱异常，缺乏美感，又臭又长！ node.js开发虽快，但也是有问题的，回调坑很大，问题不在于处理不了，而是别人不知道你的思路很难看得懂你写的代码，搞不好过段时间你自己都看不懂了。这造成两个问题，后期排错麻烦以及功能改动可能导致一系列的回调要更改。 调试基本只有原生的控制台方式靠谱，node-inspector偶尔会出现无法断点的情况。 这个世界不存在最好的语言！
我个人实践的感觉。。js回调多点并没太大可读性方面的问题，可读性关键还是看代码怎么组织。倒是异步特性用好了，很方便就能把性能榨出来。。。我目前遇到最不舒服的是回调里面处理异常，有些时候会把自己搞晕。。
@fengmk2 相对流行是一方面，好坏又是另一方面，微软xp那么流行，你能说他很好？
node的好是相对PHP，java的同步代码而言的，是相对的好。node主体采用单线程回调异步模式，部分采用了线程池，文件系统，dns.lookup（）都是采用了线程池实现的。在关键的网络通信上，node是异步的，所以在通信效率上，node就相对比同步代码效率好。java也有异步接口，但是java不像javascript这样回调函数可以比较简单自然的实现，c也可以，c也存在同样的问题。node这种模式曾经是比较先进的。
node跟nginx比在某些方面又相对不好， 尤其在静态文件处理上，node用的是线程池模拟的异步，nginx则针对不同的文件类型提供了不同的策略，对大量的小文件，直接使用同步的系统调用sendfile，对大文件，使用AIO。而nginx也有自己不擅长的，处理动态的没有node方便，虽然有openresty，但从实际使用中来看，还是没有node方便。
曾经相对先进的回调模式下的异步现在也遇到了挑战者，那就是协程（coroutine），或者叫纤程（fiber），不管叫什么名字，他们本质上都是在用户空间模拟线程，这种线程是非常轻量的，调度完全由用户自己控制（或者用户不直接控制，而是由用户态程序控制）。这种模式有两大好处，一是避免了原生线程的大消耗，原生线程在一定程序上也能实现并行，也能实现异步，但他们的好处很快被线程的切换吞噬掉了。用户空间模拟的线程切换消耗就小得多。fibjs用的是自己实现的ucontext，lua用的是longjmp。解决了切换消耗，接下来就是锁，用户空间模拟的线程本质上是单线程的函数调用，只不过这种函数调用是可控的，没有了锁开销，性能上自然又获得了不少提升。即便是node使用的锁非常轻量，性能如果想再进一步，这也是实实在在的性能杀手。当然这不是node的问题，所有只要涉及多线程的，包括协程，都会面对这个问题。
协程相对原生的线程有很多好处，相对于回调有什么好处呢？首先，他们在异步编程领域的使命是一致的，那就是保证异步编程的执行顺序，回调山大家都不陌生，为什么会出现回调山呢？回调山就是保证异步过程是按照我们所设想的步骤去执行，在需要并行的地方，我可以将异步请求一股脑儿的都发出去，这个时候我对返回的顺序没有要求。在需要顺序执行的地方，我们则需要用一层套一层的回调来保证执行顺序。回调模式下的异步避免了多线程条件下，锁的竞争问题，编程模型跟多线程锁相比简化了，在思维上可以说更接近了人类思维模式。但是回调模式跟协程相比还是存在缺陷的，协程可以通过适当的处理，模拟出同步代码的效果，但本质上还是异步的，fibjs，openresty的代码都实现了这个效果。回调不行，回调是有传染性的，要获得异步的好处，所有异步代码必须全部用回调，某段逻辑上如果存在大量的异步过程，就需要大量的回调来应对，如果正好回调内部关联比较强烈，无法将回调拆分，那么写出的代码将是又长又难调试的，大家回想一下，自己是不是碰到过某些比较复杂的代码，是自己写的，过了一段时间后自己回过头来看，几乎都看不明白了，但是谢天谢地，那段代码还能运行，但是就不知道什么时候会出问题，这种担心大家有没有？有的话，那是正常的。javascript为了应对这个问题，加入了一些类似协程的东西，generator，async/await这些东西都发展的方向。现在的node还在发育，还远没到成熟的阶段，node的发展还是要看javascript的发展，现阶段promise和generator还是太麻烦，回调模式朝形式同步的进化路上还是有坑，这些问题我们都必须要面对，javascript与lua等天生具备协程能力的语言相比，在这场竞赛中谁能出头，最关键的是看javascript能不能迅速的顺应潮流，迅速的协程化，javascript已经在改变，就是步子太过婉约，他必须兼容过去的大量回调代码，但也必须要解决形式同步的问题。说这是生死问题，一点也不夸张，程序员会用脚投票，回调山真不是必须的。
@coordcn dns.lookup 不会是瓶颈吧。如果真的很敏感，可以使用 dns.resolve 。
至于 node 去做 nginx 最擅长的事情，我觉得就没必要讨论了。正如这年头谁还会自己做静态文件服务一样。静态文件已经是一个通用服务，用各种云存储即可。
每种语言都有它的优点和缺点，所以才会百花齐放。没必要过于纠结，讨论那么多，还不如就选择自己喜欢的，深入进去就好。
@fengmk2 dns.lookup我本意并不是说它的性能问题，而是指出node实际上是使用线程的，不管是文件系统还是域名查询，线程的使用都是无奈的选择，因为没有更好的异步接口可用。
让各自做自己擅长的事情是正确的思维方式，可现实是很多人片面夸大了node的能力和好处，有意无意的回避了一些问题，看看现在这个论坛的质量就可以知道，有多少人是认真思考和调查过才投入node，当一些人没有真正思考调查过，以后再碰到一些坑，很自然的想法就是node不好，不如某某语言。事实上我们需要知道的是node优点在哪里？缺点在哪里？贪小便宜吃大亏，很多人都认为前后端统一了可以节省人力，但前后端真的一样么？前端的异步的调用能有几个？稍微复杂点的也就像sea.js，require.js等模块加载，其他的通讯跟后端不是可比的。如果一些人觉得可以统一的话，那只能说明一个问题，node所做的复杂度其实和前端相差不大，这样的确是可以统一的。这就回到了做自己擅长事情的问题上，node现阶段可以做什么，不可以做什么？我不清楚阿里怎么用的，用的深度，但是我认可大前端这种思维，node现阶段的使命就是这个，一个数据的管道。
你说的不错，语言没有最好的，只有最合适的，合适项目，合适自己。但要讲深入，这个概念太虚了，深入可以理解为能用node做一个中等规模的项目，碰到的坑自己能填满；也能理解为大体上理解了node，能够为node打打补丁；也能解释为完全理解了node，抛开能够自己实现一个。如果要讲深入，永远是没有尽头的。有的网友不是调侃《深入浅出》为《九浅一深》么？到了一定程度，深也就浅了，这是很自然的规律。
我不清楚你两年前的情况，我可以知道的是，es6刚刚开始普及，es7还在路上，我不知道你两年前是如何解决我提到的坑的。我不认为promise，generator/yield，async/await解决了问题，在我眼里只有形式同步才能真正解决问题。这里已经无需争论回调的问题了，回调好不好，看看javascript自己就明白了，回调要真好，就不会吸收这么多其他语言的特性了。说白了，node最大的不确定其实就是来自己于javascript本身，如果语言进化方向对了，皆大欢喜，一旦出了问题，比如c++，搞得复杂无比，javascript有没有这种趋势呢？我认为是有的。
你对回调和事件的看法，我建议你去认真看一看fibjs和openresty，回调和异步真的是两码事，事件只是碰巧来凑热闹而已。我本来对node是没有任何反思的，完全的脑残粉（很多人以为我质疑node是因为不会用，你们想错了，我绝对不是刚入门的吐槽，更不是宣扬什么PHP好），去年fibjs让我重新做了思考，fibjs的源码我大体看了，实现方式上我不认同，但思想上我认同的，而且我认为是比较先进的。openresty实现方式上我是认同的，但与nginx结合得太过紧密，不如node灵活。这两个项目都是中国人做的，可见中国人的创造力并不是一些人说的那么差，我们是有能力去做一些事情的，关键还是要打开心门，要敢于质疑一些现成的东西，现成的东西或许用得很舒服，但如果没有搞明白内部的原理，自己就很难有突破和超越。我对node的质疑完全不是心血来潮，而是有过仔细的调查，不管从javascript自身的发展，还是新出现的一些替代品来看，形式同步都是发展的方向。node并不是要被什么东西替代，而是要被新的思想替代。node将来可能还是node，只是不再有显式的异步而已。
我今天的预言可能大家都认为是笑话，是痴人说梦，请大家耐心一点，看两三年之后的是不是我说的，大家自然就会明白了。我做判断的基本原理就是我们所有的技术都是为了减少必要劳动，脑子能少转弯就少转弯，这里大部分高手，包括我自己，能够熟练运用回调，但我们不能放弃那些刚入门的兄弟，这些后备军就是生产力，或者node将来没有任何技巧，大家的工资会下降，但这就是趋势，谁也没办法改变，我们能够改变的唯有自己。形式同步的需求大家其实心里是明白的，只是不愿意说出来，那我就来做这个坏人，node只有突破了回调才能有更好的发展。近期只能用其他语言先替代一下，c+lua或许是一个不错的选择。
看看这个论坛的质量吧，还不够纠结么？人家把做node的当后端了么？看看多少招前端的广告，看看多少是冲着技术来的？我说了真话，把一些人的底线给捅破了，go，rust，其他语言在变，javascript本身也在变，何必再自我麻痹呢？形式同步不管你愿意不愿意，它都要来的。
我叫你去看fibjs，openresty，人家的代码会告诉你怎么写成形式同步。我能在这里说这么多话，肯定不是为了写个什么echo server，所有没必要epoll什么的。我说node的缺点，并没有否认node的优点，我认为libuv是非常棒的异步库，我自认依自己的水平，写不出libuv这样的库来，所以请问我需要再从头写一个echo sever么？等到需要说你写个代码来给我瞧瞧的时候，你是不是心里有点虚了呢？javascript是不是越来越去回调了？javascript能，我当然也能，而且我都不需要自己创造，我直接抄opengresty的代码就是，我推荐你去看一看，你去看了么？不看，你是永远不知道如何将异步变成同步的？你不看，你对generator/yield永远是一知半解的，你永远不会明白javascript竟也在悄悄的协程化。
纠结的不是我，而是刚入门的和已经很深入的，我看清楚了未来的方向，我不需要纠结，我不需要去弄个echo server，但是弄一个类似fibjs半成品还是可以的。
@tulayang这个人还记得么？被禁言了，我当时认为没必要禁言，让他发声，再从他身上来学习好的坏的，这样对大家进步有好处。但是就这样的水平，被一群不明所以的人奉为大神，这是打node的脸还是打我们自己的脸？ https://cnodejs.org/topic/550671cfc34008306435e30c
想学好node的，必须理解底层的异步是怎么回事，必须知道为什么这样，为什么不这样，这将决定大家可以走多远。PHP里有极高水平的高手，但大部分平庸，所以大家就认为PHP不行，node也是同样的道理，剧烈变化的语法，随意的编码方式，也许注定了这个游戏是高手玩的，我们真的要骗自己么？前后端通吃，多么动人的前景。我说的话或许已经触动高手们的利益了，所以才会有让我写一个echo server，看你写啊，你写不出来还瞎比比，是不是这个道理？道理不变，人在变，我万一写出来了呢？
@fengmk2 如何才能沟通得来呢？node一统天下，web编程全包？这样违心的话我说不出来，而且我也没有node必亡的意思，我是希望node有变革，向好的方向发展，而且我也以javascript语言本身的进化做了说明，去回调不是你我能左右的，我的意思这么明白，这是难沟通？我只是强调，回调不是解决异步问题的唯一方法，不要把回调等同于异步，这个难沟通么？
难沟通的是心，而不是技术本身。
node社区必须要勇敢的面对自身的问题，才能更好的发展，javascript语言都在变，都在去回调，我们有什么理由无视呢？曾经回调是优势，但如果被回调束缚住，优势也会变劣势。诺基亚，微软，无不说明了这个道理，当独霸天下的时候，自以为就没了对手，技术上就保守了，最后市场就给了颜色。中国近代为什么落后，原来我们领先那么多，东方在欧洲人眼里就是天堂，东方的财富激发他们奋不顾身的大航海，我们在别人奋发的时候却停滞不前了，做起了天朝上国的美梦，我们没有资格去批判我们的祖先，这是人性使然，但我们必须警醒。
node即便不变革，三年时间还是可以撑的，别的技术从出生到成熟，没有个三五年都显得太稚嫩了，node这方面是优势，但过去的所有一切也都可能成为包袱。沟通真的很难么？用心了就不难，看看别人的实现，对比一下，我觉得没有什么难的。
@coordcn 我想我能理解你的意思。像 c# 就一直在演化，async, await 这些，lambda 表达式，linq 系统，var 关键字, yield，有些是语法糖，但用起来真是爽歪歪。这估计也是 ms 一家主导的关系，而 js 是一个开放标准，想要快速演化是很难。先别说 generator 或者协程化之类高级特性，像 lambda 这样的语法糖其实都可以很好的简化代码，比如说 [1, 2, 3].filter(n => n > 2) 这样看起来可简单多了。其实像这样语言标准方面的问题层次太高了。放在这里讨论你很难找到共鸣，鬼佬们也不会跑到这里来看我们扯皮。
很多人不能理解回调的问题就在于他们还不没遇到过这种复杂的情况。这个光讲是很难表达出来的，没踩过不知道痛的。坑可以填，问题就是于怕别人或者日后的自己看不懂当初是不是有这个坑或为何要用这样的方式去坑这样的坑！对于写一般性的 web.js 应答，遇到这样的坑可能性比较小。所以我建议大家有空时把遇到的坑整理成需求案例，大家试着写相应的代码去解决。真刀实枪地跳坑！
兄台能在解释器源代码层次上去理解 node.js 我表示敬佩，但推荐别人也用这样方式去研究那是行不通的！阅读解释器源代码需要较高素养以及时间成本，像我这样的用户级别的人（或者将自己定位为 node.js 的使用者）是不太愿意花费这样成本去干这种 top level geek 才会干的事。而多数人看到这样的推荐第一反应会是你在羞辱我看不懂吗？在知道本社区水平不高的情况下，这样的推荐效果等同于地图攻击。
作为使用者的角度来看，是可以对语言标准指手划脚的。并且我们也具有判断语法特性是否能被实现的素养，甚至理解实现机制具体是否优秀也是可以的。但去钻研具体的实现，时间成本太高。
最后我要表示兄台的水平和探讨态度表示赞赏。无论结果如何在座各位是否能 agree to disagree, 这样的态度都是值得推荐的！
@coordcn 貌似美丽说也是这样的形式，复杂的业务用php做API，然后node只负责调用API和渲染前端界面。一直不明白为什么不直接用node写业务，原来是介个样子滴
@flftfqwxf 呃，美丽说貌似没java这层，PHP直接写业务，但都只提供API，nodejs请求API拿到数据再渲染前端。估计要求效率的地方写C扩展吧。
@coordcn 说得好~~~ 其实PHP人群和Javascript人群里面庸才占大头，因为这两种语言才容易蒙事了，不是易学难精，是门槛太低进来的低能者太多。其实使用语言的大脑才是重点，用PHP、JS的目的是飞速的解决业务逻辑。
小白指望一种语言来弥补自己空洞的大脑，那是不现实的，指望这个不如多吃点脑白金。 高手不在乎语言的，十八般兵刃样样拿得起放得下。
@i5ting 支持。我想再补充一点：从nodejs@6.x起。“node --inspect”还能够把 node运行时 直接 与Chrome中的DEV Tool（就是你调试网页的那个Dev Tool）连接起来 进行远程调试。这个新feature既能够 减少node-inspector的安装 环节，此外它的调试体验也更好。请见：https://nodejs.org/api/debugger.html#debugger_v8_inspector_integration_for_node_js
@coordcn 通过使用Babel，我在项目中已经大面积地开始使用async/await语法糖。因此，在代码中成片出现回调函数的代码已经很少见。就目前，Babel与ES7胜行的今天，我不认为回调函数还是 javascript被人们诟病的痛点。
@zlbbq 支持。我还想补充：JavaScript编码中的随意性，目前 已经 能够 通过 在项目构建过程中 引入ESLint代码静态扫描工具 进行有效的 约束。当然，更高大上的解决策略，还有 把ESLint与 js文本编译器 关联起来，输出 即时、可视化 的 语法错误提示。我正在使用的 js文本编译器是 notepad++。目前，我还没有成功地实践过这个最棒的解决策略。
我不明白，为什么“代码形式同步化”与“去回调函数”还是大家在一起激烈争论的主要焦点？在html5圈子里，这个概念已经是共识了，同时也是大家共同努力的目标。更何况，目前这个目标实现得还不错呢。ES 7里的async/await借助于Babel已经能够在日常编程中使用了。 使用async/await语法，以我的项目 经验，至少9成左右的回调函数都能够被去掉了。不光是浏览器，就算是在nodejs的运行时，也能够运行被Babel预编译之后的JavaScript代码呀。
@coordcn 在三年前，我会对你的质疑与担忧深有同感，但是今天，我认为这个不是问题：
- html5圈内，大家都 认同 “业务逻辑异步 + 代码形式同步”这个概念。
- html5圈内，大家都 以 “业务逻辑异步 + 代码形式同步”为努力目标。
- 从目前ECMAScript的标准制定，与Babel先行尝试，从generaor，到TJ CO库，再到async/await语法，都证明 #1和#2 都有很好的实践与成果。 你是不是想多了？和我们一起使用《Babel + Rollup + ES 6/7》吧。咱们又不是搞学术研究，不用这么地纠结。
一年前的帖子，还有人要跟我较劲，看来我拉的仇恨不少啊。
还是那句话，多看看我讲的到底是什么？多了解下我反对什么？然后再来发表长篇大论。
你说的东西，我大部分是赞成的。
我反对是那些把回调当宝，然后又把promise，generator当宝，现在又把async/await当宝的人。
建议多看看其他语言的实现，看看人家怎么做的？有对比才会知道自己的优点和不足。幸好，我不是你所谓圈子里的人，还能看看其他语言，还不至于被个语法糖给唬住。
没有stackfull的协程支持，你的所谓形式同步永远是显式的，传染的。你提到的这些，都只不过式过渡解决方案，是现实的无奈和妥协，如果跟其他语言比，是万不可拿来炫耀的。
当然各人有各人的选择，有的人就是喜欢显式的异步，没有关键字还不自主的担心。有的就是觉得回调异步写起来舒坦。我还听用python的朋友鄙视lua呢，说lua的语言太搓了，表现太弱，你看python的generator多好用，然后balabala一堆函数式编程的概念，什么高阶函数啊，惰性求值啊，我听得一脸蒙逼，不停的点头，不停的赞叹。但我转头，又回去写C和lua了。这就是各人的选择，我尊重各人的选择，但这不妨碍我喷某某技术。
有的东西，好就是好，不好就是不好，当然知道这个好与不好的前提是有对比。建议你得空得话，看看go，openresty，fibjs，luaio这些基于协程实现的形式同步方案，对比一下，如果抛开生态，你还觉得async/await好，我表示尊重各人的选择。
@coordcn 原来，你不是做WEB呀！那就难怪了。html5也好，js也好，他们的主要竞争力与优势都是在WEB应用场景内才能够最大化。在WEB之外，我客观地说，js与nodejs还是很弱小的，竞争力也不突出。
吃我两记鸡汤： 批判和膜拜的人都是没有深度使用过的人。 没有完美的技术，但有最适合的技术。（没有银弹）
自己也不是权威大牛，了解的也不尽完全，不敢对任何一种技术进行评价。 不过我用两年多的实践可以证明，Nodejs也可以很好的搞定整个大型项目，并且对之后的WEB发展趋势和云计算也极其友好。 只能说，Nodejs这个东西，用起来不顺手的人就不要勉强用；用起来顺手的人可以偷着乐。
@coordcn 想请教一下你说的：
形式同步永远是显式的，传染的
是否可以通过这样的代码来理解
a = fun(arg, callback)//第一种情况：异步回掉，想要得到多个异步调用同步，就必须callback里面再嵌套callback，callback传染到别的地方
a = fun().then().then()//第二种情况：跟情况1类似，如果需要同步效果，则需要then里面传递promise， promise会传染到别的地方
a = yield promise//第三种情况：出现了yield这个关键字，需要同步的地方都会有yield，yield在主干流程传染
async/await//没了解过，不做评论
上述的情况都是传染的，然后是显示的（出现各种关键字），最理想的形态应该是代码同步，但是调用异步，例如
a = async()//异步调用
b = async()//异步调用，但必须等待上一句代码完成之后才进行
在这种情况下，代码层面开起来都是同步的形式，如何去把这些异步调用同步化，则交给解释器去做了，而需要实现这个效果，就必须借助用户态线程，也就是现在node现在所没有的，或者说v8没有的。 请问这样理解正确吗？
你的理解已经非常透彻了。
只有这样才能真正摆脱显示异步带来的思维负担，专注业务逻辑。
现在js阵营大部分精力都花在为回调异步打补丁上了，现在只是实现了局部伪同步。
我认为，只要不出什么幺蛾子，js实现用户态线程应该是迟早的事情，到那个时候，js程序员就真正被解放了。
既能享受异步带来的好处，又不需要额外增加异步思维带来的负担。用户态的线程，优化做好了，可以支持千万级别的。跟直接的函数调用虽然有差距，但相对于生产效率的提升，那点开销足够多开几台服务器了。
加人，还是加机器，我选择优先加机器。这是我评判技术的一个基本原则。
时不时的就看到这样的论调，Node.js 不适合密集处理，不适合复杂逻辑，布拉布拉… 我不知道是什么挫折导致使用者有这样的幻觉出现，还说只是看到大厂在哪些方面使用Node.js就意淫一些理由。
我说说我的情况，我2011年开始接触 Node.js，之前6年左右我一直是PHP程序员， 2012年开始在公司全面推动Node.js 第一个项目我用Node.js用的非常恨，因为是数据产品，我从数据加工处理，计算，api接口全部都是Node.js 一开始异步确实跟我造成了一些困扰，现在看来这些困扰基本上是因为思维上不适应导致的。尤其是后来我接触了 async 库包，我甚至到现在完全爱上异步了。
之前PHP做的一个功能是前端来一个请求，服务器端要去一个私有的api上请求数千次，之后把结果合并返回。大家知道PHP是同步的语言，也就是数千次请求需要顺序完成，如果按5k次请求每个请求就算100ms，总共也需要500s，8分钟，基本上是太阳光找到地球需要的时间，这么长时间基本上用户不会去等，因此功能只能设计成异步的，先提交任务，等计算完毕了在来查看。同样这个功能换成Node.js根本不需要先提交任务，直接请求过来，后端实时的请求计算，我用async 并发量控制在100，基本上10来秒就完成全部请求。
最近几天我有在用Node.js做csv数据的统计，附加各种过滤条件 ，用的lazy.js这个库。后续我可能会把统计csv这不分功能抽象后封装成库包开源出来，性能挺高的，1秒钟基本上处理 1w行数据。
对了补充上面的，2012年开始推广Node.js目前公司全部产品都是Node.js的，各种简单的，复杂的，并没有听谁抱怨说那些地方不适合，见到最多的就是对异步的不适应，注意我说不适应，一旦适应了完全会爱上异步。
