JavaScript异步编程教程：Promise与async/await详解

本文深入剖析了JavaScript异步编程的核心机制，明确指出Promise与async/await并非并列替代方案，而是同一异步模型的底层抽象与上层语法糖——Promise是不可逆的状态机，负责精确控制异步操作的生命周期和错误传播；async/await则通过微任务调度营造线性编码体验，大幅提升业务逻辑的可读性与可维护性。文章直击开发者高频误区：从Promise构造时遗漏resolve/reject、链式调用中隐式返回undefined，到await误用导致串行阻塞、微任务与React状态更新的时机冲突，并强调真正关键的不是语法正确性，而是清醒判断当前代码是在“协调异步状态”还是“编排业务步骤”，从而在封装底层能力（选Promise）与表达业务流程（选async/await）之间做出精准分层决策。

Promise 是什么？不是“容器”，而是状态机

它不“装”数据，而是代表一个**尚未确定结果的异步操作的状态流转过程**。只有三种不可逆状态：pending → fulfilled 或 rejected。一旦 settled（即 fulfilled/rejected），状态再也不会变。

• 常见错误：把 new Promise 当作“启动异步”的开关，却忘了必须显式调用 resolve 或 reject，否则永远卡在 pending，且无任何报错
• 链式陷阱：每个 .then() 都返回新 Promise，但若内部没 return，后续 .then() 会收到 undefined，而不是上一步的值
• 错误捕获盲区：只写 .then(success) 不写第二个参数，失败会被吞掉；推荐统一用 .catch() 放最后，但注意它只能捕获前面链中抛出的错误或 rejected 的 Promise

async/await 是怎么“暂停”函数的？

它根本没暂停 JS 引擎——只是让函数在遇到 await 时自动 return 一个 Promise，并把后续逻辑注册为微任务。所谓“暂停”，是开发者视角的线性错觉。

• 必须在 async 函数里用 await，否则报 SyntaxError: await is only valid in async functions
• await 后面如果不是 Promise，会自动包装成 resolved 状态的 Promise（例如 await 42 等价于 await Promise.resolve(42)）
• 想并发执行多个请求？别写 await a(); await b();——那是串行。改用 await Promise.all([a(), b()])，否则性能直接砍半

什么时候该用 Promise？什么时候该用 async/await？

不是“哪个更高级”，而是“谁更适合当前职责”：

• 封装底层能力（如自定义超时、重试、节流异步调用）→ 直接操作 Promise 构造器和静态方法（Promise.race、Promise.allSettled）更灵活
• 业务逻辑编排（比如“先登录 → 再拉用户信息 → 最后初始化配置”）→ 用 async/await 配合 try/catch，错误路径清晰，调试体验接近同步代码
• 需要在非 async 函数里消费异步结果（如 React class 组件的 componentDidMount）→ 只能用 .then()，因为不能加 async 到生命周期方法上（会破坏返回值语义）

最常被忽略的细节：微任务 vs 宏任务执行时机

Promise.then 回调和 await 后续代码都属于微任务（microtask），会在当前宏任务（如点击事件、setTimeout 回调）结束后、下一次渲染前立即执行。这点直接影响 UI 更新节奏和竞态处理。

• 现象：连续多次 setState + await 后立刻读取 state，发现还是旧值 → 因为 React 的批量更新机制与微任务执行顺序交织，需用 useEffect 或 flushSync 显式控制
• 调试技巧：在 await 后加 console.log('after await')，再加一个 setTimeout(() => console.log('in timeout'), 0)，就能直观看到微任务先于宏任务执行
• 隐患：大量嵌套 await + 微任务，可能造成事件循环阻塞感（尤其在低端设备），应主动拆分耗时逻辑，避免单次微任务队列过长

以上就是《JavaScript异步编程教程：Promise与async/await详解》的详细内容，更多关于的资料请关注golang学习网公众号！