`await Promise.all`与`X = await Promise.all`的内存占用差异及V8优化问题

两种写法是否存在内存使用差异 #

两者存在内存差异，但差异和多数人直觉中「不接返回值就不会创建数组」的判断完全无关。

• 按照ES规范的强制要求，Promise.all的执行流程是固定的：只要传入的所有promise都成功兑现，它就必须生成一个包含所有兑现值的连续数组，作为自身的最终返回结果，不管这个结果最终有没有被外层代码捕获。
• 这意味着两种写法在Promise.all从pending状态转为fulfilled状态的瞬间，会产生完全一致的内存峰值——也就是题目场景里10万个结果对应的100KB数组存储开销，加上JS数组本身的元数据、传入的10万个promise对象的引用存储开销。两种写法在峰值阶段的内存占用没有本质区别。

第一种“不捕获返回值”写法的实际内存占用 #

这个写法的内存释放节奏和第二种写法有显著区别：

1. 等待执行阶段：内存开销和第二种写法完全一致。不管接不接返回值，Promise.all内部都会维护一个计数器、一个结果存储数组，用来在所有promise完成时拼装最终返回值，这部分开销和外层是否接收结果没有任何关系。
2. await执行完成阶段：因为没有把最终生成的结果数组绑定到X这类长期存在的变量上，这个数组在await对应的微任务执行完成的瞬间就变成了无引用的垃圾对象。只要没有其他代码意外持有这个数组的引用，它就会被V8的垃圾回收机制快速回收，不会长期驻留在内存中。
   反观第二种写法，只要X还在当前作用域的可达路径上（比如是全局变量、或者被闭包引用的局部变量），这个100KB的数组就不会被GC回收，会一直占用有效内存。

V8引擎针对未捕获返回值的优化逻辑 #

V8确实会针对这类场景做优化，但不存在“跳过返回数组创建”这类违反规范的优化：

• 规范层面不允许跳过数组创建：如果V8在没有捕获返回值的场景下直接不生成结果数组，就会破坏标准兼容性——万一这个Promise.all的返回值被其他中间逻辑持有（比如被上层的拦截器透传、被全局的错误处理逻辑引用），就会出现返回值缺失的诡异bug。
• V8实际做的优化是即时引用解除：当引擎扫描字节码执行流程时，发现await Promise.all的返回值没有被赋值给任何变量、没有被作为函数返回值透传、也没有被其他闭包引用时，会在await的微任务执行完成后立刻解除对这个结果数组的引用，不需要等整个函数执行完毕、作用域销毁时才释放引用。
• 这类优化能大幅降低无意义的内存驻留时间，但不会降低内存峰值。那个100KB的结果数组依然会被完整创建出来，只是创建完成后马上就变成可回收的垃圾，不会长时间占用内存。

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