Node.js环境下变量传参与直接传对象的内存影响分析

代码示例 #

写法1（提前声明变量传参）

async function getDataFromExternalAPI(bodyPayload) {
  // 发送请求获取数据
}

var bodyPayload = {a: 1, b: {}};
await getDataFromExternalAPI(bodyPayload);

写法2（直接传入对象字面量）

await getDataFromExternalAPI({a: 1, b: {}});

核心结论 #

两种写法在内存占用和性能表现上几乎没有可感知的差异，写法1不存在实质性的额外性能弊端，常规开发场景下优先选择可读性更高的写法1即可。

内存层面的差异说明 #

两种写法仅在对象引用的持有逻辑上有微小区别：

• 写法1中额外声明的bodyPayload变量本身只会占用极少量栈内存：64位Node.js环境下仅占8字节，用来存储对象在堆内存中的地址指针，而存储{a: 1, b: {}}实际数据的堆内存空间，两种写法的占用完全一致。
• 若后续代码没有再用到bodyPayload变量，该变量离开作用域后，V8垃圾回收机制会同时回收变量本身的栈空间和它指向的堆内存空间，和写法2的回收时机几乎没有差别。
• 写法2中对象字面量创建后直接作为参数传入函数，没有额外变量持有引用，函数执行完成后对象会被更快标记为可回收，但这个时间差在所有业务场景下都可以忽略不计。

性能层面的影响说明 #

Node.js使用的V8引擎有成熟的编译优化能力，几乎会抹平两种写法的性能差异：

• V8的逃逸分析可以识别出bodyPayload不会逃逸出当前作用域，编译阶段会直接将两种写法优化为完全一致的机器码，不会产生额外的赋值开销。
• 即使没有触发优化，额外的变量赋值操作损耗在纳秒级别，远低于调用外部API的网络IO开销，不可能成为性能瓶颈。

如果后续逻辑需要复用该请求参数对象，写法1反而可以避免重复创建对象，性能更优。只有在极端场景（比如循环内创建百万级以上临时对象且无及时回收）下才有可能感知到差异，常规开发完全不需要为此牺牲可读性。

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