我什么时候应该使用 Q.defer，什么时候应该使用 Promise.resolve/reject？答案

【问题标题】：When should I use Q.defer and when just Promise.resolve/reject?我什么时候应该使用 Q.defer，什么时候应该使用 Promise.resolve/reject？
【发布时间】：2016-02-10 10:19:30
【问题描述】：

我正在使用 nodejs，想知道什么时候应该使用 Q defer，什么时候只使用 Promise.resolve/reject？

我看到了很多这两种类型的例子，例如：

// with Q defer
fucntion oneWay(myVal) {
  var deffered = Q.defer();
  if (myVal < 0) {
    deffered.reject(new Error('nope'));
  } else {
    deffered.resolve('yay');
  }
  return deffered.promise;
}

// native Promise
fucntion orAnother(myVal) {
  if (myVal < 0) {
    return Promise.reject(new Error('nope'));
  } else {
    return Promise.resolve('yay');
  }
}

有什么区别，什么时候使用 difer 比较好？

Promise.resolve/reject (native) 和 Q.resolve/reject 有什么区别吗？它们都返回承诺，但当我在节点控制台中查看返回值时，它看起来不同。

谢谢

【问题讨论】：

不清楚上下文（前端 FW 作为 Angular、节点应用程序等）以及你用 Promise 引用什么（原生 ES6 承诺，像 Bluebird 这样的库？）
你是对的。我已经说得更清楚了（节点和原生承诺）
它们或多或少是相同想法的替代实现。使用您喜欢的任何一个。
如果您可以访问本机 Promise，我建议您使用它并且不要导入外部库来做一些您可以在没有它的情况下完成的事情。如果您需要更多承诺功能，请查看 Bluebird 或 When libs

标签： javascript node.js promise q deferred

【解决方案1】：

没有理由使用 Promise 构造函数，或者 - worse - 一个延迟的，当你不需要的时候。您的函数中没有任何异步内容，因此您不需要（也不应该使用）回调。

只需选择Promise.resolve/Promise.reject 或它们的Q 对应物，然后直接构造一个值的承诺。无论如何，它更短更简单。

另见Promise constructor with reject call vs throwing error。

什么时候使用 defer 比较好？

从来没有。即使在Q，你也应该使用Q.Promise。

Promise (native) 和 Q 有什么区别吗？当我查看节点控制台中的返回值时，它们看起来不同。

嗯，它们是不同的类，具有不同的属性，而Q 承诺确实有更多的方法。
但它们的工作方式相同，并且彼此完全可以互操作。

【讨论】：

那么就不需要推迟了吗？（也在异步函数中？）
是的，defer 已被 promise 构造函数完全弃用。
太好了，谢谢！即使在Q's documentation 中，这也确实令人困惑，他们展示了 defer 的使用