async函数必定返回promise，无论return值为何都会被自动包装为promise.resolve()或promise.reject()，这是引擎内置规则而非开发者选择。
JavaScript 中的异步函数（async 函数）并不是“必须显式返回 Promise”，而是语言规范强制规定它总是返回 Promise——无论你写不写 return，也无论你返回的是数字、字符串还是 undefined，结果都会被自动包装成 Promise.resolve(...)。
async 函数返回 Promise 是设计使然，不是可选项
这不是一个需要开发者“主动选择”的行为，而是 JavaScript 引擎在解析 async 函数时就内置的规则：
-
async function foo() { return 123; }→ 返回Promise.resolve(123) -
async function bar() { throw new Error('oops'); }→ 返回Promise.reject(new Error('oops')) -
async function baz() {}（没写 return）→ 返回Promise.resolve(undefined)
这种统一包装确保了调用方始终能以一致方式消费返回值：用 await 或链式 .then()，而不用判断“这次是不是同步返回”。它消除了类型歧义，是异步流程可组合性的基础。
所谓“显式返回”，其实是误解的源头
很多人说“要显式返回 Promise”，实际想表达的是：如果函数逻辑本身依赖异步操作，就必须让最终值通过 Promise 流出。但这个“显式”并非指手动写 return new Promise(...)，而是指：
- 别在
async函数里混用同步返回和异步返回（比如if (x) return 'sync'; else return await api();），这会让调用方拿到的类型不一致（有时是 string，有时是 Promise） - 如果中间调用了另一个
async函数，记得await它，否则你返回的是一个 pending Promise，而不是它 resolve 后的值 - 不需要手动
return Promise.resolve(...)——async已经替你做了；直接return value就行
不返回 Promise 的后果：调用方无法等待
假设你写了一个 async 函数却忘了 await 内部的异步调用：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
async function getUser() {
return fetch('/api/user').then(res => res.json()); // ❌ 忘了 await
}
它返回的不是一个用户对象，而是一个 Promise（而且是未等待完成的嵌套 Promise）。外部用 await getUser() 拿到的仍是 pending 状态的 Promise，不是数据本身。真正该写的是：
async function getUser() {
const res = await fetch('/api/user'); // ✅ 先 await 响应
return await res.json(); // ✅ 再 await 解析
}
这里的 return 不是“显式构造 Promise”，而是让最终值自然落入 async 的自动包装机制中。
什么时候不该用 async？
如果你发现总在想办法“绕过 Promise 包装”（比如 async () => { return someSyncValue; }），说明函数本就不该标记为 async：
- 没有
await，也没有异步依赖 → 直接用普通函数 - 只是想复用
await语法 → 那就要接受它附带的 Promise 返回契约 - 想让调用方拿到原始值而非 Promise → 去掉
async，改用同步逻辑或明确约定回调方式
硬加 async 又试图“取消 Promise”，只会让接口语义混乱、类型不可靠、调试更困难。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
