Typescript 笑话：等待vs setImmediate vs useFakeTimers vs newpromise（setImmediate）

下面是TypeScript中的一个笑话测试。我想知道为什么需要setImmediate（）

第一个例子是一个有效的测试。接下来是我尝试过的各种不起作用的东西。我不明白到底发生了什么。pubsub.publish的签名为：

（方法）PubSub.publish（triggerName:string，payload:any）：Promise

test.only（'subscriptions'，async（）=>{
const document=parse(`
订阅{
创造
}
`)
const sub=等待订阅（模式、文档）；
expect（sub.next）.tobededefined（）
//setInterval和process.nextTick也在此处工作：
setImmediate（（）=>pubsub.publish（'CREATE_ONE'，{CREATE:'FLUM！}））//这很有效
const{value:{errors，data}}=wait sub.next（）
expect（errors.toBeUndefined（）
expect（data）.toBeDefined（）
expect（data.create）.toBe（'FLUM！'）
}, 10000)

所以这些是我尝试过的其他事情，一些是在研究了类似问题的答案之后。所有这些尝试都失败，测试出现超时异常：

test.only（'subscriptions'，async（）=>{
//尝试#1:jest.useFakeTimers（）
const document=parse(`
订阅{
创造
}
`)
const sub=等待订阅（模式、文档）；
expect（sub.next）.tobededefined（）
//#1，续：
//publish（'CREATE_ONE'，{CREATE:'FLUM！'}）
//或者。。。
//等待pubsub.publish（'CREATE_ONE'，{CREATE:'FLUM！'}）
//不过，这与之前的测试一样有效，但使用了假计时器：
//setImmediate（（）=>pubsub.publish（'CREATE_ONE'，{CREATE:'FLUM！}））
//尝试#2：
//等待pubsub.publish（'CREATE_ONE'，{CREATE:'FLUM！'}）
//尝试#3：
//publish（'CREATE_ONE'，{CREATE:'FLUM！'}）
//等待新的承诺（立即生效）
//尝试#3a（变体）：
//等待新的承诺（（决议）=>setImmediate（决议））；
const{value:{errors，data}}=wait sub.next（）
expect（errors.toBeUndefined（）
expect（data）.toBeDefined（）
expect（data.create）.toBe（'FLUM！'）
}, 10000)

我理解setImmediate将函数放入事件循环中，以便在任何挂起的I/O事件之后立即执行。我不知道为什么需要它，因为pubsub.publish（）返回的承诺可以通过wait处理，但在这种情况下，下一行wait sub.next（）永远不会被调用

我的想法是，在pubsub.publish（）中有一个setInterval调用，setImmediate会等待任何挂起的setInterval事件完成（对此我的理解是模糊的）。尝试3和3a是我在别处找到的实现这一点的机制，但在这种情况下它们似乎不起作用

---

问题：为什么这个测试要求setImmediate通过？

所以我的困惑是因为setImmediate做了什么和没有做什么。这就是正在发生的事情：

    // setInterval and process.nextTick also work here:
    setImmediate(() => pubsub.publish('CREATE_ONE', { create: "FLUM!" })) 
    const { value: { errors, data } } = await sub.next()

如果没有setImmediate（），则在调用sub.next（）之前发送发布事件，因此不会捕获它。您可能认为setImmediate（或process.nextTick）会导致立即执行publish函数，但不会。相反，setImmediate会将发布调用延迟足够长的时间，以便sub.next（）执行

---

我现在将对setImmediate和process.nextTick的实际工作方式进行一些补救性阅读。

可能与publish（）返回的异步迭代器的延迟初始化有关？graphql订阅中存在此问题：