return await 比 return promise 多触发一次微任务：前者先等待 promise settle 再 Promise.resolve() 包装结果，后者直接返回原 promise，无额外微任务。
return await 会多触发一次微任务调度
在 async 函数中，return await promise 和 return promise 表面结果相同，但底层微任务行为不同。
前者先等待 promise settle，再把返回值包装进一个新的 Promise.resolve()；后者直接将该 promise 作为函数返回值，不额外插入微任务。
例如：
-
async function f1() { return await fetch('/api'); }→ fetch 返回的 Promise settle 后，f1 内部再走一次 Promise.resolve(result)，产生一次额外微任务 -
async function f2() { return fetch('/api'); }→ fetch 返回的 Promise 直接成为 f2 的返回值，无新增微任务
执行步数差异：多一次 resolve 微任务
V8 引擎对 async 函数的处理是：只要函数体里有 await，整个函数就由 spawn 机制驱动，而 return await 会在 await 完成后，再调用一次 Promise.resolve() 包装结果。
立即学习“Java免费学习笔记（深入）”；
这导致比直接 return 多一个「微任务注册 → 执行 → 返回」的环节。虽然单次开销极小，但在高频调用（如渲染循环、大量并发请求封装）中会累积可观延迟。
Chrome DevTools 的 Performance 面板中可观察到：return await 版本在 microtask queue 中多出一条 PromiseResolveThenableJob 记录。
实际影响取决于 Promise 类型
如果 await 的是已 settled 的 Promise（如 Promise.resolve(42) 或缓存的 Promise），return await 的额外开销更明显——因为 await 立即恢复，紧接着又触发一次无意义的 Promise.resolve。
而若 await 的是 pending 状态的 Promise（如未完成的 fetch），两次 resolve 行为会被合并优化一部分，但微任务队列长度仍比直接 return 多 1。
建议场景：
- 需要统一错误处理或中间转换时，用 return await（如 await x().catch(...)
- 仅作透传、追求极致性能时，优先 return x()
替代写法：用 Promise.resolve().then() 更可控
若需链式处理但避免 return await 的冗余，可用：
-
return promise.then(x => transform(x))—— 不引入新微任务，且保持扁平链 -
return promise.catch(err => handleError(err))—— 比 try/catch + return await 更轻量
这类写法跳过 async 函数的 spawn 封装层，直接操作原 Promise，微任务步数与 return promise 一致。
