节点; Q承诺延迟

Question

这是一些基于行为的简单问题，我在下面的示例中在节点上运行时注意到了这些行为：

Q('THING 1').then(console.log.bind(console));
console.log('THING 2');

输出为：

> "THING 2"
> "THING 1"

1）为什么要Q实现在立即对已知值运行回调之前等待？为什么不够Q智能，以至于第一行在第二行运行之前同步发布其输出？

2）什么是之间的时间流逝"THING 2"和"THING 1"被输出？它是单个进程滴答吗？

3）能否将绩效深深包裹在承诺中而产生绩效问题？例如，Q(Q(Q("THING 1")))即使可以有效地同步解决，它是否也要异步等待3倍的时间才能完成？

Answer 1

这实际上是有目的的。无论值是否已知，都必须保持一致。这样，只有一个评估顺序，您可以依赖以下事实：无论承诺是否已兑现，该顺序都是相同的。

同样，否则，将有可能编写代码来测试诺言是否已兑现，并且通过设计不应当知道并兑现诺言。

这几乎就像回调样式的代码一样：

function fun(args, callback) {

    if (!args) {
        process.nextTick(callback, 'error');
    }
    // ...
}

这样任何人都可以通过以下方式调用它：

fun(x, function (err) {
  // A
});
// B

可以确保A永远不会在B之前运行。

规格

看到承诺/ A +规范，该then方法部分中，点4：

onFulfilled或onRejected在执行上下文堆栈仅包含平台代码之前不得调用。

另请参见注释1：

这里的“平台代码”是指引擎，环境和承诺实现代码。实际上，此要求可确保在调用之后的事件循环之后以及使用新堆栈时，onFulfilled和onRejected异步执行。这可以通过“宏任务”机制（如setTimeout或setImmediate）或“微任务”机制（如MutationObserver或process.nextTick）来实现。由于promise实现被视为平台代码，因此它本身可能包含任务调度队列或在其中调用处理程序的“蹦床”。

因此，这实际上是规范要求的。

为了确保明确此要求，我们进行了广泛讨论-请参阅：

• https://github.com/promises-aplus/promises-spec/pull/70
• https://github.com/promises-aplus/promises-spec/pull/104
• https://github.com/promises-aplus/promises-spec/issues/100
• https://github.com/promises-aplus/promises-spec/issues/139
• https://github.com/promises-aplus/promises-spec/issues/229