为何async函数返回Promise而非直接值？其设计意义何在？

Great question—this gets right to the heart of how async/await integrates with JavaScript's asynchronous programming model. Let's break this down to match your two core questions:

1. Why does an async function return a Promise instead of the direct value? #

At its core, async/await is just syntactic sugar for Promises. JavaScript engines are hardwired to automatically wrap any return value from an async function in a resolved Promise—no matter if you return a primitive number, an object, or even undefined.

For example:

async function getAnswer() {
  return 42;
}
// This is exactly equivalent to:
function getAnswer() {
  return Promise.resolve(42);
}

This wrapping happens because async functions are meant to represent asynchronous operations, even if the code inside doesn’t explicitly use await. The goal here is consistency: you never have to guess whether a function will return a value synchronously or a Promise—it always returns a Promise, so you can reliably use .then() or await to handle its result.

2. Why return a Promise at all, instead of the direct result or void? #

This boils down to three critical design choices that keep asynchronous code predictable and compatible:

Consistency across async and sync code paths #

Even if an async function uses await to "synchronize" its internal logic, the function itself is still asynchronous from the caller’s perspective. Imagine if async functions returned direct values:

async function fetchUser() {
  const response = await fetch('/api/user'); // Execution pauses here
  return response.json();
}

const user = fetchUser(); // What would this value be?

When fetchUser() is called, the await fetch(...) line hasn’t finished yet. Returning a direct value would leave user as undefined (or a half-completed state) because the async operation isn’t done. A Promise lets the caller wait for the operation to finish before accessing the result, using either await or .then().

Compatibility with the existing Promise ecosystem #

JavaScript’s asynchronous tooling—like Promise.all(), .then() chains, and Promise.race()—is built entirely around Promises. If async functions returned raw values, they couldn’t seamlessly integrate with these tools. For example:

async function getFirstItem() { return "apple"; }
async function getSecondItem() { return "banana"; }

// Works because both return Promises
Promise.all([getFirstItem(), getSecondItem()])
  .then(items => console.log(items)); // Logs ["apple", "banana"]

If these functions returned raw strings instead of Promises, Promise.all() would fail to work as expected—breaking compatibility with the entire asynchronous ecosystem that existed before async/await was introduced.

Unified error handling #

Async functions automatically catch any thrown errors (both synchronous and asynchronous) and convert them into rejected Promises. This means you can handle all errors from an async function in one place: either with a try/catch block (if using await) or a .catch() handler.

If async functions returned direct values, error handling would split into two separate paths: one for synchronous errors thrown before any await, and another for asynchronous errors from awaited operations. This would make code far harder to reason about and debug.

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