@youlong723687543

精通是一个很神奇的概念。

有的时候，仅仅是知道，也可以算精通； 有的时候，搞了个helloworld；也可以算精通； 有的时候，搞了个简单的小项目，可以算精通了； 有的时候，做了点比较大的项目，能够解决node本身的一些坑，这个可以算精通； 有的时候，通读了node的源代码，能够为node打打补丁，也可以是精通； 有的时候，node已经不再满足自己要求了，自己一时兴起，重新搞一个，这不知道能不能算精通了。

其实大家都不清楚什么叫精通，大概是满足了自己公司用人标准，或者在什么牛逼的公司里干过了，就是精通了。说到底，那些要求精通的人自己也搞不清楚什么叫精通，精通或许就是看你比较顺眼，你就精通了。。。

@youlong723687543 明白了就好，node缺陷是很明显的，用得越深入，你就越觉得自己需要了解的越多，不但node本身是坑，node的各种库也有坑。这里所谓的大神，也就顶多到能填坑的水平。

node和javascript语言本身的很多缺陷就能造就很多所谓的牛人，然而，这一切真的必要么？其实根本没什么卵用，平白耗费了不少脑细胞，还不见得有什么收益。高性能现在新出来哪个不是奔着高性能去的？两三年前可以牛逼一下，现在性能也就那样，普通水平而已。前后端通吃更是痴人说梦，前后端的复杂度根本不是一个级别的，前端干得好就能干后端，除了个别牛人，其他都是神话，不要相信一些人瞎吹，人家根本没把node当后端，人家取了个好听的名字叫大前端，小公司，小项目，创业做demo用用蛮爽，其实就这样而已，真正后端还是其他语言支撑的。

我的意思不是不要学node，node要学，但是对node要有个清醒的认识，node仅仅是一个选项而已，node仅仅是一个表皮而已，你需要深入的是node背后的东西，node本身其实已经没有多大价值了，高性能的先行者已经被自己束缚住了手脚了。你理解了node为什么要这样或那样设计，你用node碰到的坑自己就会填，你不知道原理，坑你没商量。结论反而是，如果你下定决心学node，你就必须深入的学，否则的话，等于没学。你学习的结果应该不是依赖于node，而是逐步认清node的好与不好，而不是像某些人学成了脑残粉，装大神，其实卵都不懂。

判断自己真懂还是假懂了，真懂的很清楚node各种好，也很清楚各种不好，各种坑，知道node需要改进的地方，假懂的就是脑残粉，别人不能说node半点不好，觉得node好牛逼，神圣不可侵犯，其他技术都是渣渣，其实这些人根本没有深入的使用和研究，仅仅是自我感觉自己掌握了一门绝门武功而已，别人怎么可以说这门武功不好呢？

这个论坛里的脑残粉现在可以来喷我的，下面开始列队。

@youlong723687543 你其实已经很明白了啊，这要比那些脑残的明白多了，基本上知道了好与不好了，接下来就好办了。最怕的就是不知所谓的，以为自己天下无敌的。

node原理搞明白没（cluster，eventemitter，net，http都是怎么实现的）没搞明白，最好看看源代码，可能一遍两遍不会有什么收获，坚持读进取就慢慢明白了，先从lib文件夹里读起，选自己常用的模块，看看具体是怎么实现的，node的lib其实是比较好的例子，代码写得比很多项目要规范得多， 考虑问题也很周到。然后是src文件夹，这里就是libuv跟v8做绑定的，给lib调用的，两个对照起来看，就明白大概的数据流向，明白回调是怎么来的。再往后就是读下libuv，libuv是非常优秀的异步库，是我非常喜欢的，虽然它是因node而生，但离开node，它依然很优秀。同时你也要了解一下es6的相关内容，对node来说，回调已不是重点，但必须知道回调的原理，明白回调是如何保证执行顺序，明白哪些是并行的，哪些是顺序的。然后就是用es6的语法糖将回调转换成伪同步。做这个过程如果有一个项目可以实践，顺便读下koa源代码，基本上你就修成正果了。

然而上面的过程也就读node和libuv源代码是有用的，其他都没什么卵用，es6的语法糖拯救不了node，形式同步才是异步的终极目标。回调和generator/yield都不是异步的终结，异步的终结是代码里不需要有显式的异步。koa不过是是临时救急的角色，搞明白了它只是开始，你接下来还要搞明白所有原有的回调库，并把回调全部转换成伪同步。在做这一切的时候，你要死掉不少脑细胞。

下面的链接里，演示了如何用同步代码来写异步程序，最后一个回复。 https://cnodejs.org/topic/55838f3401d3ce0d73d68ead

很多会javascript的前端以为找到了可以证明自己的救命稻草，可以过把后端的瘾，但我很实在的告诉大家，除非自己非常牛逼，能够像openresty的作者一样从前端做到后端，自己实现模块，否则的话，还是老老实实做前端吧，前后端通吃只是一个神话，不要相信，不要迷恋，看现在招人火热的创业公司，两年后97%都会死掉，现在牛逼吹得震天响的都是忽悠。一个最简单的道理，一个个跟风的公司能有什么伟大的创意？都是抄袭或被抄袭的命。

@wenshiqi0

协程有多种实现方式，可以用ucontext（fibjs自己用汇编实现了ucontext），也可以用longjmp（lua），就开销来说，函数调用小于longjmp，longjmp小于ucontext，ucontext小于线程，线程小于进程。但权衡效率损失和编码效率来说，协程肯定是优于回调，回调本身不是问题（认为回调本身是问题的多半没有真正理解异步，可以这样说，没有回调也就没有了异步，在c层面的异步是无法避免的。），回调带来的问题才是问题，错误处理，跟踪调试，才是真正的问题所在。如果回调没有任何问题的话，generator就没有出现的必要，这是整个技术发展的必然，回调如果的是复杂的，那么我们就有必须引入一个东西来避免复杂，这就是generator的意义所在，通过适当的变换（其实还是回调，只不过这个回调不再由开发者显式的调用，而是通过某种约定让框架可以代为调用，在形式上看起来没有回调，只有yield关键字，这个过程付出的代价就大于协程切换的开销了），让异步回调实现了形式上的同步，可以立即进行错误处理，跟踪调试自然也简单得多。但我必须要强调，generator并不是真正意义上的协程，而是一个半调子的四不像，它即要付出协程切换的代价，也要付出回调函数调用的代价。在实现上的复杂度上其实是超过回调的，本质上属于用一个复杂的技术去解决另一个复杂的技术所面临的问题，表面上有改善，但仅仅是对普通用户而言，表面上是很爽，但普通用户理解其原理将更加困难。现在有更简单的，更容易理解的，直接协程化的方法，node不管在开销上还是在编码效率上都落后了。这是 node必须要面对的现实，如果node的创始人当初不反对协程，而是接纳，今天的node完全可以反过来影响es6标准，实现一个更加简单方便的协程，而不是现在被动的接受这种不伦不类的奇怪东西。