直接then/catch与包裹Promise的异步写法区别及性能对比咨询

嘿，这两种写法的核心区别其实在于它们的适配场景和代码冗余度，性能上几乎没差，我给你拆解一下：

1. 核心用途与逻辑差异 #

写法一（直接使用原Promise + 回调） #

client.query(query1)
  .then(data => {
    callback(null, { statusCode: 200, body: JSON.stringify(data) });
  })
  .catch(err => {
    callback(null, { statusCode: 500, body: JSON.stringify(err) });
  });

这种写法是把client.query返回的原生Promise，直接适配成了传统的Node.js回调模式（即callback(err, result)的形式）。它的目的是让基于Promise的异步操作，能在只接受回调函数的老代码环境里运行——比如早期的Express中间件、或者一些依赖回调的工具函数。

写法二（手动包裹新Promise） #

return new Promise((resolve, reject) => {
  client.query(query2)
    .then(data => {
      resolve({statusCode:200, body: JSON.stringify(data)});
    })
    .catch(err => {
      reject(err);
    });
});

这种写法其实是冗余的Promise包装——因为client.query本身已经返回了一个Promise，完全不需要手动再创建一个新的Promise来包裹它。它的意图是对外暴露一个Promise接口，但其实可以简化成更简洁的形式：

return client.query(query2)
  .then(data => ({ statusCode: 200, body: JSON.stringify(data) }))
  .catch(err => { throw err; });

这段简化后的代码和原写法二的功能完全一致，但避免了不必要的Promise嵌套。

2. 性能对比 #

两者的性能几乎没有差异：

• 写法二只是多创建了一个Promise对象，这个对象的内存开销和运行时消耗微乎其微，在实际业务场景中完全可以忽略不计。
• 核心的异步操作都是client.query数据库查询，这才是性能的瓶颈所在——两种写法都没有改变这个核心步骤的执行逻辑，所以不存在谁比谁更快的情况。

3. 代码优劣与适用场景 #

• 如果你的代码环境要求用回调函数处理结果（比如老项目的回调式API），写法一完全没问题，是合理的适配方式。
• 如果需要对外返回Promise接口，写法二的冗余包装是没必要的，直接返回client.query链式调用后的Promise即可，代码更简洁，也符合Promise的最佳实践（避免手动包装已有的Promise，也就是所谓的「Promise反模式」）。

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