javascript异步编程如何理解_promise和async_await是什么【教程】

promise 是代表异步操作状态流转的状态机，仅有 pending→fulfilled/rejected 三种不可逆状态；async/await 是其语法糖，通过自动返回 Promise 并注册微任务实现“暂停”假象，二者应按职责分工使用。

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 更新节奏和竞态处理。

立即学习“Java免费学习笔记（深入）”；

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

真正难的不是写对语法，而是判断“这一段异步流程，我到底是在协调状态，还是在组织业务步骤”。混用 Promise 链和 async/await 不是错误，但若不清楚每一步的返回值类型和错误传播路径，undefined 和未捕获的 rejection 就会准时出现。