异步承诺返回函数的同步与异步执行

当制作返回承诺的异步函数时，在每个实现中我都看到了这种做法：

function asyncFunction() {
 return new Promise((resolve,reject) => {
  // the function code
  if (condition) resolve()
  else reject()
 })
}

换句话说，执行器函数中的函数代码是同步运行的，只有 Promise 结算和回调调用是异步完成的。这对我来说是违反直觉的，因为当我想到异步函数时，我想到的是一个函数，当它执行时，立即返回，并将其操作推迟到以后。这是一个例子：

function asyncFunction() {
 return new Promise((resolve,reject) => {
  setTimeout(() => {
   // the function code
   if (condition) resolve()
   else reject()
  }, 0)
  
 })
}

这意味着函数的代码将在任务中执行，并且在返回的 Promise 上注册的所有回调将作为微任务运行。该函数立即返回，并且不会使线程挨饿。

我现在有几个问题。

1. 我的推理正确/有意义还是我没有看到一些边缘情况？
2. 异步函数有什么特点？我看到两个表征异步函数特征的候选参数：1. 立即返回并稍后运行其计算；2. 回调稍后/异步运行。对我来说，这种函数的唯一特征是第一点，但正如我在我能找到的所有代码中看到的那样，唯一重要的是回调是异步运行的。
3. 使用我的代码版本而不是第一个版本有什么优点/缺点吗？

承诺是工具manage异步代码，而不是使代码异步。

您的第一个示例根本不应该使用承诺。该函数所做的一切都是阻塞的。使用承诺只会增加复杂性。 （例外情况是，如果您正在编写代码来匹配有时用于异步操作的接口）。

你的第二个例子也是毫无意义的（至少几乎总是如此）。正在添加超时just让事件循环继续处理函数之外的内容，然后再重新拾取它。这can很有用（例如，允许浏览器在执行耗时的操作之前重新绘制窗口），但方法应该是：

1. 我需要在下一个操作运行之前重新绘制窗口
2. 我将在该操作之前运行超时
3. 我将使用 Promise 来管理该代码

…而你的代码seems扭转这一局面，从承诺开始，并试图证明其使用的合理性。

如果您有一些耗时的代码要运行并且您不希望它阻止主事件循环，那么您可能应该使用worker所以它在不同的线程上运行。您可能会使用 Promise 来处理该代码，并将其结果发送回主事件循环。