当从异步函数内部调用它们时，是否有任何理由更喜欢 Node.js 中函数的异步版本？

Question

主要看 FS api，对于大多数功能来说，似乎有三种风格可供选择：

1. 同步
2. 使用回调异步
3. 异步使用 Promise

异步是使用系统资源的更好方法，但是，如果我已经在异步函数中并且正在等待每个调用，那么这与仅使用同步调用之间应该没有任何区别，对吗？对我来说，它就像一个内置的等待语句。

我不知道异步是如何在 js/node 中实现的。如果我一开始就在异步函数中，那么使用异步函数有什么好处吗？（不包括并行运行异步任务时的场景）

Answer 1

async人们应该仅根据该函数内部发生的情况来决定使用该函数，而不是根据谁调用它。调用者不会影响函数是否应该存在async。

创建函数的原因async：

1. 您在函数内部有基于承诺的异步操作，并且您希望使用await.
2. 您的函数内部有基于 Promise 的异步操作，并且您希望利用在调用异步操作之前可能发生的同步异常（以及转换为被拒绝的 Promise）的自动捕获功能。

async这就是在函数前面使用关键字的原因。

async函数不属于的东西（或关于async函数的常见误解）：

1. 它不会神奇地使阻塞代码变成非阻塞。
2. 它不会使调用者运行得更快。
3. 它不会使同步代码现在在后台异步运行。

异步是使用系统资源的最佳方式，

不确定你的意思是什么。异步函数允许您以非阻塞方式运行操作，以便 Javascript 中的主线程可以在异步操作运行时执行其他操作，但这不是函数async可以实现的。这是通过异步操作实现的。两者不同。

如果我已经在异步函数中并且正在等待每个调用，那么这与仅使用同步调用之间应该没有任何区别，对吧？

不正确。与返回 Promise 的函数一起使用await确实会挂起当前函数的执行（立即返回 Promise），但这允许主 Javascript 线程执行其他操作、服务其他请求等……使用同步代码会阻塞并且会阻塞。不允许主线程做其他事情，从而破坏服务器的可扩展性。

对我来说，它就像一个内置的等待语句。

阻塞同步代码会影响操作期间可能运行的所有其他内容。它与使用不一样await。