先抛个核心观点：**在 async 函数中主动抛出 Error 实例，对应的 Promise 状态会立即变为 rejected，这并非什么神奇特性，而是语言将 async 函数视为 Promise 语法糖之后自然产生的结果。** 深入底层，JavaScript 引擎对 async 函数的编译与执行逻辑，本质上是一套“Promise 状态机的自动化管理机制”。当你正常 return 一个值时，引擎会隐式地帮你 resolve；当你抛出 Error 时，引擎会立刻帮你 reject。中间根本不存在任何过渡状态。 ### 编译机制本质上就是包装了一个 Promise 链 当你定义 `async function` 时，V8（或其他引擎）并不会将其当作一个独立函数执行，而是自动将其嵌入到一个隐式的 Promise 构造器中。具体来说： - 函数体会被当成 executor 来运行，但引擎不允许你直接调用 resolve/reject，它自己在幕后进行管理。 - 普通的 `return value` → 对应隐式的 `resolve(value)`。 - `throw new Error(...)` → 对应隐式的 `reject(error)`，并且 Error 实例本身会被原封不动地传递下去。 - 这个 reject 动作**不会经过任何中间包装**，Promise 内部状态直接从 pending 跳转为 rejected，error 实例被绑定为 reason。 因此，在抛出 Error 的瞬间，引擎就已经确定了 Promise 的状态，后续所有的 .catch()、await、外层 try/catch 获取到的就是这个原始的 Error 对象——它的 stack、message、name 等属性一个都不会少。 ### 错误即触发 Promise 拒绝协议 这一机制完全符合 Promise/A+ 规范与 ECMAScript 标准。async 函数体内的同步异常（包括 throw）会被引擎捕获，并**同步映射为 Promise rejection**。具体链路如下： - throw 触发 → 当前执行流立即中断，后续代码不再执行。 - 该 Error 实例被直接写入 Promise 的 [[PromiseResult]] 内部槽位，作为 rejection reason。 - 状态标记 [[PromiseState]] 同步设置为 "rejected"，且不可逆转。 - 随后 .catch()、await、外层 try/catch 才能获取到这个 Error。 整个过程是同步完成的——严格来说，这个 Error 在 async 函数体执行到 throw 那一行时就已经被彻底确定，不存在任何异步延迟。 ### 与 Promise.reject() 本质上是一回事 换个角度来看，你可以把 async 函数中的 `throw new Error("msg")` 看作是语法上更自然的 `return Promise.reject(new Error("msg"))`。两者最终都会导致同一个 Promise 被 rejected，reason 完全相同。唯一的区别在于书写风格：throw 是同步异常语句，reject 是显式的 Promise 操作。但底层触发的状态变更路径、时机和数据结构，完全一致。 ### 但细节上有个小坑：非 Error 值也能 reject，只是调试体验极差 虽然 `throw "oops"` 或 `throw 42` 同样能让 Promise 变为 rejected，但不会自动构造 Error 对象。也就是说，reason 只是一个字符串或数字，**没有 stack trace**。这在日志、监控、开发者工具中根本无法定位问题源头。因此，统一使用 `new Error()` 是最稳妥的做法——既符合规范，也有利于可观测性。 不复杂，但容易忽略：**async 函数的“错误即 rejection”不是模拟出来的，而是语言层面对 Promise 状态机的原生对接。** 你写的每一个 throw，引擎都会认真对待，并且绝不给你留后悔的机会。