Node.js Lambda返回响应后未await的Promise是否会执行完成？

首先明确核心规则：你在handler中未加await调用_helper()时，handler返回响应不会立刻主动终止_helper的执行，但_helper也没有任何一定会执行完成的保证，最终能不能跑完完全是概率性事件，绝对不能在生产逻辑里依赖这个行为。

具体逻辑可以拆成两点说：

• 从Node.js本身的运行机制看，_helper()被调用后，它的异步链式逻辑已经被放进了事件循环队列，只要进程还在正常运行，没有被冻结、回收，这些排队的任务就会按顺序继续执行，不会因为handler函数return就被主动清除。
• 但Lambda的运行环境不是常驻的普通Node.js服务：当handler返回响应后，Lambda服务会在很短的窗口期后直接冻结当前执行实例的进程，此时事件循环会被完全暂停，所有没跑完的异步任务都会卡在当前的await节点，既不会继续执行，也不会抛出错误。如果后续这个实例没有被复用来处理新请求，直接被回收了，那没跑完的_helper就相当于执行失败了。

拿你给出的代码举例子：_helper里的固定逻辑耗时最少是150ms（第一次查库）+500ms（事务），如果触发通知还要再加100ms，总耗时在650ms-750ms区间。绝大多数情况下Lambda返回响应后预留的空窗期远小于这个时长，大概率你的dbTransaction还没跑完，进程就被冻结了，直接导致数据库事务中断、通知漏发的问题，而且这类问题偶发，排查难度极高。

注意：哪怕某次请求里_helper运气好赶在进程冻结前跑完了，也不代表这个写法是可行的。Lambda的冻结时机完全由平台控制，没有任何稳定性保证，你不能把核心业务逻辑建立在不确定的平台行为上。

如果你的业务需要_helper的逻辑全部执行完成再给用户返回响应，必须在调用时加await _helper()；如果不需要等待_helper的执行结果，应该把任务投递到专门的异步消息队列，用独立的消费者处理任务，不要指望靠Lambda返回后的空窗期跑后台任务。

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