async函数预处理不检查await合法性，异常安全依赖运行时：返回值总为Promise，await自动包装非Promise值，但空值调用、同步抛错和未捕获reject仍需主动防护。
async 函数在执行前会经历 JavaScript 引擎的预处理阶段，但这个阶段**不检查 await 语句是否合法、不验证 Promise 状态、也不捕获潜在异常**。真正的异常安全机制发生在运行时，而非预处理阶段。
预处理阶段不涉及 async/await 逻辑
JavaScript 的预处理（hoisting）只处理声明类语法：var、function、class、const、let。它为变量和函数分配作用域与初始绑定，但完全忽略 async 函数体内的 await、try/catch 或 Promise 构造逻辑。
这意味着：
- 一个包含
await undefined或await null的 async 函数，在预处理时不会报错，甚至能顺利通过语法解析 -
async function bad() { await 123; }合法通过预处理——因为 123 不是 Promise，但 await 会自动用Promise.resolve(123)包装，运行时不会崩溃 - 只有语法错误（如
await写在非 async 函数里、缺少右操作数、括号不匹配）会在解析阶段被拦截，不属于预处理范畴
异常安全靠运行时保障，不是预处理责任
async 函数的异常安全性体现在两个层面：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
返回值总是 Promise：无论 return 基本类型、throw 错误，还是隐式结束，函数都返回 Promise，调用方可通过
.catch()或try/catch + await统一捕获 -
await 自动适配非 Promise 值：
await 42、await 'ok'、await undefined都会被转为Promise.resolve(...)，不会抛出 TypeError - 真正会触发异常的情况，如
await Promise.reject(new Error('boom'))或await fetch('/api').then(r => r.json())中 JSON 解析失败，都发生在 Promise 执行期，属于运行时行为
真正需要防范的“异常盲区”
预处理不管，运行时又自动兜底，容易让人误以为 async 函数天然健壮。但以下情况仍需主动防护：
-
await 后接可能为 null/undefined 的 Promise 创建函数：例如
await maybeApiCall?.()，若maybeApiCall为 undefined，会报TypeError: undefined is not a function，这发生在 await 求值前，无法被 await 自动处理 -
同步抛错未被 try/catch 包裹：async 函数体内第一行就
JSON.parse(invalid)，错误同步抛出，Promise 尚未创建，此时await fn()的调用方 catch 不到，必须在函数内部捕获 -
未处理的 rejected Promise：忘记
.catch()或顶层try/catch，会导致 UnhandledRejection，虽不中断执行，但影响可观测性与调试体验
写法建议：让异常路径清晰可追溯
不必依赖预处理做校验，但可通过习惯提升鲁棒性：
- 对可能为空的异步调用源加空值检查：
if (api) await api() - 把易出错的同步操作（如 JSON.parse、new URL）放在 try 块内，而非 await 表达式右侧
- 顶层 async 函数调用尽量包裹
try/catch，或监听window.addEventListener('unhandledrejection', ...) - 避免在 await 后直接链式调用可能失败的方法，如
await fetch(...).json()→ 应拆成两步，便于单独捕获网络响应失败与解析失败
