await 后跟非 Promise 值时，V8 会隐式调用 Promise.resolve 包装为已兑现 Promise，该行为由 AsyncFunctionAwait 字节码指令在运行时强制执行，与微任务调度强绑定，不可绕过且性能接近显式包装。
当 await 后面跟的是非 Promise 值（比如数字、字符串、对象、undefined），V8 并不会报错，而是自动把它“变成”一个已兑现的 Promise。这个过程不是语法糖层面的简单替换，而是引擎在字节码生成和执行阶段就固化下来的隐式行为。
await 对非 Promise 值的统一处理逻辑
V8 在编译 async 函数时，会把每个 await 表达式都当作需要接入微任务队列的节点来对待。无论右边是什么类型，引擎都会走同一套状态机路径：
- 若右侧值本身是 Promise 实例（或 thenable），直接注册其
.then回调到微任务队列 - 若右侧值是原始值（
42、"hello"、null等）或普通对象，V8 内部会立即创建一个Promise.resolve(value)等效的 promise，并把后续代码作为它的.then回调入队 - 这个包装动作发生在运行时，由 V8 的
AsyncFunctionAwait字节码指令触发，不依赖用户写的 JS 代码
从字节码看隐式包装的不可绕过性
用 node --print-bytecode 查看如下函数：
你会看到其中包含 AsyncFunctionAwait 指令，它底层必然调用类似 PromiseResolve 的内置函数——哪怕你传的是字面量。这说明：隐式包装不是 Babel 或 TypeScript 编译器做的，而是 V8 执行引擎的硬性规范实现。
为什么必须包装？和微任务调度强绑定
await 的语义本质是“暂停当前 async 函数，把剩余逻辑推入微任务队列”。这个“暂停-恢复”机制依赖于 Promise 状态机与事件循环的协作。如果允许跳过包装直接同步返回，就会破坏以下关键约束：
- 所有
await表达式后的代码，都必须在当前宏任务结束前、下一个宏任务开始后执行（即严格落在微任务阶段） - 多个
await链的执行顺序必须可预测，不能因值类型不同而分裂为同步/异步两条路径 - 错误传播（如
throw被catch捕获）需统一走 Promise rejection 流程
实际影响：别依赖“同步快感”
有人误以为 await 42 比 await Promise.resolve(42) 快，其实两者在 V8 中性能几乎一致——因为后者省略了 Promise.resolve 构造调用，但前者仍要走完整的 promise 创建 + 微任务注册流程。真正有差异的是：
- 显式写
Promise.resolve(x)可能触发额外的隐藏类切换或内联缓存失效 - 隐式包装由引擎高度优化，路径更短，且与 async 函数上下文深度耦合
- 调试时看到的堆栈里，隐式包装的 promise 没有用户代码痕迹，更难追踪来源
