JavaScript中return await究竟有无用武之地？

Chavin
5,902 阅读5分钟

我先回答：有的，参考文章末尾。

有没有区别？

 先上一个Demo，看看async函数中return时加和不加await有没有区别：

function bar() {
  return Promise.resolve('this from bar().');
}

async function foo1() {
  return await bar(); // CASE#1 with await
}

async function foo2() {
  return bar(); // CASE#2 without await
}

// main
(() => {
  foo1().then((res) => {
    console.log('foo1:', res); // res is string: 'this from bar().'
  })
  foo2().then((res) => {
    console.log('foo2:', res); // res is string: 'this from bar().'
  })
})();

 可能在一些社区或团队的编程规范中，有明确要求：不允许使用非必要的 return await。给出的原因是这样做对于foo函数而言，会增加等待bar函数返回的Promise出结果的时间（但其实它可以不用等，因为马上就要return了嘛，这个时间应留给foo函数的调用者去等）。

 如果你觉得上面的文字读起来很晦涩，可以直接带着问题看代码，问：以上例子中，foo1()函数和foo2()函数的写法对程序的执行过程有何影响？

 先说结论：async 函数中 return await promise; 和 return promise; 从宏观结果来看是一样的，但微观上看有区别。

有什么区别？

 基于上面的Demo改造一下，做个实验：

const TAG = Symbol();
const RESULT = Promise.resolve('return from bar().');
RESULT[TAG] = 'TAG#RESULT';

function bar() {
  return RESULT;
}

async function foo1() {
  return await bar();
}

async function foo2() {
  const foo2Ret = bar();
  console.log('foo2Ret(i):', foo2Ret[TAG], foo2Ret === RESULT); // 'TAG#RESULT', true  (1)
  return foo2Ret; // without await
}

// main
(() => {
  const foo1Ret = foo1();
  console.log('foo1Ret:', foo1Ret[TAG], foo1Ret === RESULT); // undefined, false  (2)
  console.log('--------------------------------------------');
  const foo2Ret = foo2();
  console.log('foo2Ret(o):', foo2Ret[TAG], foo2Ret === RESULT); // undefined, false  (3)
})();

 从注释标注的执行结果可以看到：

  • (1)处没有疑问，foo2Ret 本来就是 RESULT；
  • (2)处应该也没有疑问，foo1Ret 是基于 RESULT 这个Promise的结果重新包装的一个新的Promise（只是这个Promise的结果和Result是一致的）；
  • (3)处应该和常识相悖，竟然和(2)不一样？是的，对于 async 函数不管return啥都会包成Promise，而且不是简单的通过 Pomise.resolve() 包装。

 那就可以得出结论了，async 函数中 return await promise; 和 return promise; 至少有两个区别：

  1. 对象上的区别：
    • return await promise; 会先把promise的结果解出来，再构造成新的Promise
    • return promise; 直接在promise的基础上构造Promise，也就是套了两个Promise（两层Promise的状态和结果是一致的）
  2. 时间上的区别：假设 bar() 函数耗时 10s
    • foo1() 中的写法会导致这10s消耗在 foo1() 函数的执行上
    • foo2() 的写法则会让10s的消耗在 foo2() 函数的调用者侧，也就是注释为main的匿名立即函数

 从对象上的区别看，不论怎样async函数都会构造新的Promise对象，有无await都节约不了内存；从时间上来看，总体的等待时长理论上是一样的，因为两种写法对结果都没啥影响嘛。

 但是，笔者这里举个不那么恰当的例子：假如你的Leader交给你一个重要任务，需要你完成后发邮件给他。你分析了下，后发现该任务需要同事A做一部分，遂找他；同事A说要完成他那部分需要2天。

 此时的你有两个做法可供参考：

  1. 做完自己的部分后等着A出结果，有结果后再发邮件回复Leader；
  2. 将自己的部分完成后汇报给Leader，并和Leader同步A部分的情况：即告知Leader让A需要额外耗时，并已让他在完成后直接发邮件给Leader。

 假如（我是说假如哈~），这个任务非常重要，DDL要求在12H内完成，但实际耗时两天严重超标，给团队造成了极大损失......那么请问，上述哪种做法更容易获取N+1大礼包？

到底怎么写？

 回到代码层，通过上述分析可以知道，一个主要是耗时归属问题，一个是async函数“总是”会返回的那个Promise对象不是由Promise.resolve()简单包装的（因为Promise.resolve(promise) === promise），可以得到两个编码指南：

  1. async 函数中应该尽可能避免多余的 Promise.resolve() 包装
  2. 只有在需要使用 try-catch-finaly 处理逻辑时才使用return await
    • 如异常捕获、执行记录等

补充下，async函数不是通过Pomise.resolve()简单包装的，其实进一步思考下也不难理解，因为JS运行时需要考虑执行有异常的场景，甚至还可能要根据不同的Promise状态做一些其他的操作（比如调试日志输出、埋点统计？未查源码纯属瞎猜）

// 避免return await 影响模块耗时统计，和额外资源消耗
async function foo() {
  return bar();
}

//（1）但需要消费执行过程中的异常时
async function foo() {
  try {
    return await bar();// 同 bar().catch(() => null);
  } catch (_) {
    return null;
  }
}
//（2）以及需要记录执行状态或统计执行时间的时候
async function foo() {
  // 以Loading状态为例
  isLoading = true;
  try {
    return await bar();
  } finaly{
    isLoading = false;
  }
}

// async 函数中避免对返回值再使用多余的 Pomise 包装
async function bar() {
  return 'this is from bar().'; // YES
}
async function bar() {
  return Promise.resolve('this is from bar().'); // !!! NO !!!
}

最后回到标题：JavaScript中return await有无用武之地？

答：有的，当在需要消化掉依赖的 Promise 中的异常，或需要记录依赖的 Promise 的执行状态（如最终状态、运行耗时）时。

以上。最后更新于
2023-11-04.长沙

avatar
文章
阅读
粉丝