怎样理解javascript异步编程_javascript中如何使用promise

promise 是解决回调地狱的链式异步处理机制，非提速魔法；其 executor 同步执行，resolve/reject 回调在微任务队列中运行；需显式调用 resolve/reject 切换状态，then 总返回新 Promise 并自动包装返回值。

Promise 是什么，不是什么

Promise 不是让代码“变快”的魔法，它只是把回调函数的嵌套关系，变成链式调用的结构。它解决的是“回调地狱”，而不是网络延迟或 CPU 计算慢的问题。你写一个 new Promise()，构造函数里的执行器（executor）会**立即同步执行**，但它的 resolve 或 reject 回调，一定是在当前任务队列清空后、下一轮微任务中才运行。

怎么创建和消费一个 Promise

最常踩的坑是：以为 Promise 构造函数里写个异步操作就自动“返回 Promise”了——其实必须显式调用 resolve(value) 或 reject(Error) 才算完成状态切换。

• 构造时传入一个函数，该函数接收 resolve 和 reject 两个参数
• resolve 触发 then 分支；reject 触发 catch 或 then(NULL, handler)
• then 总是返回一个新的 Promise，所以能链式调用；返回值会自动包装成 Promise（除非返回另一个 Promise）

const fetchUser = () => {   return new Promise((resolve, reject) => {     setTimeout(() => {       const success = Math.random() > 0.3;       if (success) {         resolve({ id: 1, name: 'Alice' });       } else {         reject(new Error('Network failed'));       }     }, 200);   }); };  fetchUser()   .then(user => {     console.log('Got user:', user);     return user.name.toUpperCase();   })   .then(name => console.log('Uppercase:', name))   .catch(err => console.error('Error:', err.message));

常见错误：忘记 catch、误用 return、混用 await

Promise 链一旦漏掉 catch，错误就会静默丢失（尤其在生产环境没开 unhandledrejection 监听时）。另外，很多人在 then 里写了异步操作但忘了 return，导致后续 then 拿到 undefined。

• 永远在 Promise 链末尾加 .catch()，或用 try/catch 包裹 await
• 在 then 中发起新异步操作（如另一个 fetch），必须 return 它，否则链中断
• await 只能在 async 函数内使用；直接在顶层写 await fetch(...) 在某些环境（如老版 node.js）会报语法错误

Promise.all 和 Promise.race 的实际取舍

这两个方法看起来很酷，但用错场景反而引入 bug。比如 Promise.all 是“全成功才成功”，只要一个 reject，整个就失败——这不一定是你想要的“并行请求”。而 Promise.race 返回第一个 settled（无论 fulfill 还是 reject）的结果，容易误把超时错误当正常响应。

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

• 需要所有请求都成功才继续 → 用 Promise.all([...])
• 只想取最快的那个响应（比如多个 cdn 接口选最快的）→ 用 Promise.race([...])
• 想并发请求、各自独立处理错误 → 改用 Promise.allSettled([...])（ES2020+）
• 想实现超时控制 → 不要用 race 简单包一层，要确保 timeout 的 Promise 一定 reject，且原 Promise 被取消（注意：原生 Promise 无法取消，需配合 AbortController）

真正难的不是写对语法，而是判断某个逻辑是否该用 Promise 封装、什么时候该退回到 callback 或改用 async/await。比如事件监听器里反复触发的异步动作，Promise 一次性的语义反而不合适——这时候可能更该用 Observable 或手动管理状态。