JavaScript调用栈、事件循环与微任务队列执行逻辑及异步实践疑问

我在API中需要获取缓存数据并执行数据库更新查询，编写的代码运行正常，但对执行逻辑存在误解。请解释以下代码的调用栈、事件循环与微任务队列行为：

const slowDbUpdate = () => {
    return new Promise((res, rej)=>{
        setTimeout(()=>{
            return res("DATA UPDATED");
        }, 10000);
    })
}

const fastCacheGet = () => {
    return new Promise((res, rej)=>{
        setTimeout(()=>{
            return res({ cache: "fast", db: "slow" });
        }, 1000);
    })
}

const test = async () => {
    try {
        slowDbUpdate().then(res => console.log(res));
        const data = await fastCacheGet();

        return data;
    } catch (error) {
        console.log("Error", error);
    }
}

执行代码补充：

test().then(res => console.log(res));

我原本的错误理解：

1. 函数test被推入调用栈并开始执行。
2. JS调用slowDbUpdate函数，将其.then方法的回调推入微任务队列。
3. 随后调用fastCacheGet函数，也将相关回调推入队列。
4. 1秒后fastCacheGet的Promise resolve，但事件循环未处理其回调。
5. 10秒后slowDbUpdate的Promise resolve，事件循环才将两个回调推入调用栈执行。

但实际运行时，1秒后返回缓存数据并打印{ cache: "fast", db: "slow" }，10秒后打印"DATA UPDATED"。

另外，我使用Node.js+Express后端，想了解：

• 这种先返回响应再完成异步任务的实践是否合理？
• 高频调用下还存在哪些风险？

调用栈与事件循环的完整流程 #

1. 初始执行阶段

   • 全局代码执行，调用test()，test函数被推入调用栈开始执行。
   • 执行slowDbUpdate()：创建Promise，内部的setTimeout被放入定时器宏任务队列（延迟10秒），此时Promise处于pending状态，.then的回调暂未进入任何队列（只有当Promise resolve时，回调才会被推入微任务队列）。
   • 接着执行await fastCacheGet()：调用fastCacheGet()创建Promise，内部的setTimeout被放入定时器宏任务队列（延迟1秒）；await会暂停test函数的执行，将test函数从调用栈弹出，等待Promise resolve。

2. 1秒后：fastCacheGet的定时器触发

   • 定时器宏任务执行：调用fastCacheGet内部的setTimeout回调，resolve Promise，此时fastCacheGet的Promise状态变为fulfilled。
   • Promise resolve后，对应的await恢复逻辑（即test函数剩余的执行代码）被推入微任务队列。
   • 事件循环处理完当前宏任务后，立即清空微任务队列：将test函数重新推入调用栈，继续执行const data = ...，然后test函数返回data，此时test()返回的Promise被resolve，其.then的回调（打印data）被推入微任务队列。
   • 微任务队列再次被清空：执行test().then的回调，打印{ cache: "fast", db: "slow" }，至此1秒时的所有任务完成。

3. 10秒后：slowDbUpdate的定时器触发

   • 定时器宏任务执行：调用slowDbUpdate内部的setTimeout回调，resolve Promise，此时slowDbUpdate()的.then回调被推入微任务队列。
   • 事件循环处理完当前宏任务后，清空微任务队列：执行.then的回调，打印"DATA UPDATED"。

你之前理解的错误点 #

• 错误认为调用Promise时就会把.then回调推入微任务队列：实际上只有当Promise状态变为fulfilled/rejected时，对应的.then/.catch回调才会被添加到微任务队列。
• 错误认为两个Promise的回调会等待到最后一起执行：fastCacheGet的Promise先resolve，对应的微任务会被优先处理，不会等待slowDbUpdate的任务完成。

实践合理性 #

这种先返回缓存响应、后台异步执行数据库更新的模式是合理的，常见于以下场景：

• 对响应速度要求高，允许数据短期最终一致性（比如商品列表缓存、用户基本信息展示）；
• 数据库更新操作耗时较长，不想让前端等待更新完成再接收响应。

高频调用下的风险 #

• 数据库连接耗尽：高频调用会触发大量异步数据库更新请求，如果没有做连接池限制，可能导致数据库连接被占满，无法处理其他请求。
• 任务堆积与内存溢出：Node.js的事件循环如果被大量未完成的异步更新任务占满，会导致任务队列堆积，内存占用持续升高，最终可能引发进程崩溃。
• 更新失败无重试/告警：后台异步任务如果执行失败（比如数据库宕机），没有重试机制或告警的话，会导致缓存与数据库数据不一致，且无法及时发现问题。
• 并发更新冲突：同一数据被高频更新时，可能出现并发写入冲突，导致数据覆盖或错误（比如库存扣减、统计数据累加）。
• 进程退出丢失任务：如果Node.js进程意外退出，正在执行的异步更新任务会直接丢失，没有持久化机制的话无法恢复。

内容的提问来源于stack exchange，提问作者VeeBee