node.js - Node ; Q promise 延迟

Question

以下是一些基于我在 Node 中运行的示例中注意到的行为的简单问题:

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) 深深包裹在 promise 中的值是否会存在性能问题？例如，Q(Q(Q("THING 1"))) 是否会异步等待 3 倍的时间才能完成，即使它可以有效地同步解析？

Answer 1

这实际上是故意的。就是为了让这个值无论已知与否都保持一致。这样就只有一个评估顺序，并且您可以相信这样一个事实:无论 Promise 是否已经解决，该顺序都是相同的。

此外，否则可以编写代码来测试 promise 是否已解决，并且根据设计，它不应该被知道和执行。

这几乎就像执行这样的回调式代码:

function fun(args, callback) {

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

这样任何调用它的人都可以:

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

可以确定A永远不会先于B运行。

规范

请参阅Promises/A+ Specification , The then Method部分，第 4 点:

onFulfilled or onRejected must not be called until the execution context stack contains only platform code.

另请参阅the note 1 :

Here "platform code" means engine, environment, and promise implementation code. In practice, this requirement ensures that onFulfilled and onRejected execute asynchronously, after the event loop turn in which then is called, and with a fresh stack. This can be implemented with either a "macro-task" mechanism such as setTimeout or setImmediate, or with a "micro-task" mechanism such as MutationObserver or process.nextTick. Since the promise implementation is considered platform code, it may itself contain a task-scheduling queue or "trampoline" in which the handlers are called.

所以这实际上是规范所强制的。

进行了广泛讨论，以确保此要求清晰 - 请参阅:

• 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