代码同步不会影响效率吗？为什么同步编码是一种胜利？ 我在做一些研究时发现了这两个链接:http://bjouhier.wordpress.com/2012/03/11/fibers-and-threads-in-node-js-what-for/ , https://github.com/Sage/streamlinejs/
如果目标是防止意大利面条式代码，那么显然您可以使用异步代码，例如 streamline.js，这不是回调金字塔，对吗？
最佳答案
你必须在这里区分两件事:
- Node 的
fs.readFileSync、fs.statSync等同步函数。所有这些函数的名称中都有一个Sync(*) .这些函数是真正的同步和阻塞。如果你调用它们，你会阻塞事件循环并杀死 Node 的性能。您应该只在服务器的初始化脚本(或命令行脚本)中使用这些函数。 - fibers 或 streamline.js 等库和工具。这些解决方案允许您以同步风格 编写代码，但您使用它们编写的代码仍将异步执行。他们确实不会阻塞事件循环。
(*) require 也是阻塞的。
Meteor 使用 纤维。它的代码是用同步风格编写的，但它是非阻塞的。
胜利不在于性能方面(这些解决方案有自己的开销，因此它们可能会稍微慢一些，但它们也可以比缓存等特定代码模式的原始回调做得更好)。胜利以及开发这些解决方案的原因在于可用性方面:它们让您以同步风格编写代码，即使您正在调用异步函数。
2017 年 1 月 25 日编辑:我创建了 3 个要点来说明非阻塞纤维: fibers-does-not-block.js , fibers-sleep-sequential.js , fibers-sleep-parallel.js
关于node.js - 为什么meteor.js是同步的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12150049/