await同步函数的运行时隐含影响：性能、内存与事件循环问题

示例代码 #

interface SomeInterface {
  bar(): Promise<string> | string
}

class SynchronousImplementation implements SomeInterface {
  bar(): string {
    return 'Hello Sync!'
  }
}

class AsynchronousImplementation implements SomeInterface {
  bar(): Promise<string> {
    return Promise.resolve('Hello Async!')
  }
}

class ConcreteClass {
  constructor(
    private readonly implementation: SomeInterface
  ) {}

  foo() {
    return this.implementation.bar()
  }
}

(async () => {
  const asynchronousImplementationInstance = new AsynchronousImplementation()
  const synchronousImplementationInstance = new SynchronousImplementation()
  const someConcreteClassInstance = new ConcreteClass(asynchronousImplementationInstance)
  const anotherConcreteClassInstance = new ConcreteClass(synchronousImplementationInstance)

  const someResult = await someConcreteClassInstance.foo()
  const anotherResult = await anotherConcreteClassInstance.foo()
})()

问题 #

在运行时层面，使用await调用实际为同步的函数（如await anotherConcreteClassInstance.foo()），是否会产生性能、内存占用、事件循环相关的不良隐含后果？

回答 #

用await处理同步返回的非Promise值，不会产生值得关注的性能、内存或事件循环问题，具体细节如下：

• 事件循环层面：当await后跟的不是Promise时，JS引擎会自动将其包装为已决议的Promise，随后将当前async函数的后续逻辑放入微任务队列执行。这个过程的开销极小，不会阻塞事件循环，也不会导致宏任务被延迟——微任务本身就是在当前宏任务执行完毕后立刻处理的，对于同步值的包装操作几乎是瞬时完成的。

• 性能与内存：现代JS引擎（比如V8）对这种场景有专门优化，包装Promise的内存开销可以忽略不计，性能损耗也微乎其微。只有在极端高频的调用场景（如每秒数百万次重复调用）下才可能察觉到细微差异，但绝大多数业务场景下完全无需担心。

• 代码层面的优势：这种统一用await处理的写法反而能提升代码一致性——不管底层实现是同步还是异步，调用方都不需要做分支判断，减少了代码复杂度，降低了出错概率。

如果确实追求极致性能，也可以手动判断返回值是否为Promise再决定是否使用await，但这种优化在绝大多数场景下属于过度优化，反而会增加代码复杂度，得不偿失。

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