async/await 是 Promise 的语法糖，async 函数必返回 Promise，await 只能在 async 函数内使用且仅等待 Promise，普通值会被自动包装；错误需 try/catch 捕获，否则触发未捕获拒绝；调试时注意执行时机仍在事件循环中。
async 和 await 不是用来“学语法”的工具，而是为了解决「明明写了异步逻辑，却总拿不到想要的值」这个实际问题。它们不是魔法，只是 Promise 的语法糖——用对了省心，用错了反而更难 debug。
async 函数一定返回 Promise，不管你愿不愿意
哪怕你写 async function foo() { return 42; }，调用 foo() 得到的也不是 42，而是一个 Promise { 42 }。这是所有混乱的起点。
- 想拿到真实值？必须用
await foo()（在另一个async函数里）或foo().then(...) - 直接在普通函数里调用
foo()并赋值给变量，得到的是 Promise 对象，不是结果——比如const res = foo(); console.log(res)打印的是Promise {} - 没
return？自动等价于return Promise.resolve(undefined)
async function getValue() {
return "done";
}
console.log(getValue()); // Promise { 'done' }
console.log(await getValue()); // SyntaxError: await is only valid in async functions
await 只能等 Promise，但会“自动兼容”普通值
await 后面接的表达式，如果是普通值（数字、字符串、对象），它会立刻包装成 Promise.resolve(...)；如果是 Promise，就真等它 resolve 或 reject。关键在于：它只在 async 函数内部有效。
- 常见错误：
await写在非async函数里 → 报错SyntaxError: await is not allowed in this context - 别以为
await 123会卡住——它不会，只是立刻返回123；真正“等待”的是像await fetch('/api')这类返回 Promise 的调用 - 如果你封装了一个老接口（比如
uni.request或XMLHttpRequest），它本身不返回 Promise，那await就完全无效——必须先用new Promise(...)包一层
function legacyApi() {
return { data: "old" };
}
async function wrapper() {
const a = await legacyApi(); // ✅ 没问题，a === { data: "old" }
const b = await fetch("/api"); // ✅ 真正等待网络响应
return b;
}
错误处理不能只靠 try/catch，还要防“未捕获拒绝”
try/catch 能捕获 await 表达式中 Promise reject 的错误，但它救不了你漏掉的 Promise 链尾部。
- 如果
await someAsyncFn()抛错，且你没写catch，错误会变成未处理的 Promise rejection，控制台报黄警告，Node.js 可能直接退出进程 - 多个
await串行时，一个失败，后续不会执行——这是优点，但也要意识到“流程中断”是默认行为 - 想让某个
await失败也不中断后续？得手动用.catch(() => null)或await Promise.resolve().catch(...)把错误吞掉
async function riskyFlow() {
try {
const user = await fetchUser(); // 如果这里 reject，下面不会执行
const profile = await fetchProfile(user.id);
return { user, profile };
} catch (err) {
console.error("流程中断在", err.message);
throw err; // 或者 return null / fallback
}
}
调试时别被“看起来同步”骗了
代码看着像同步，但执行时机仍在事件循环里。最典型的坑是：你在 await 后面加断点，以为能“看到结果”，结果发现变量还是 undefined——因为那个 await 还没完成，断点停得太早。
立即学习“Java免费学习笔记（深入）”；
- Chrome DevTools 中，对
await行设断点，按 F8 单步时，会真正等到 Promise settle 后再进下一行——这是优势，但前提是 Promise 确实已创建并运行 - 如果
await后面是个还没触发的定时器或未发起的请求，断点会“悬停”，容易误判为卡死 - 别在
await前后混用setTimeout或Promise.resolve().then()来“测顺序”——这只会加深对微任务/宏任务的误解
async 函数里，到底有多少层 Promise 嵌套、谁负责 reject、谁该处理错误、以及——那个被你 await 的东西，是不是真的返回了 Promise。 
