Promise通过链式调用替代callback地狱，核心是将嵌套回调转为线性结构；需正确包装回调API、确保resolve/reject调用、避免then内嵌回调，并善用Promise.all/allSettled/race及错误处理。
Promise 怎么替代 callback 地狱？
Promise 的核心价值不是“更高级”，而是把嵌套回调变成可链式处理的线性结构。你不需要重写所有异步逻辑，只要把老式 callback 接口包装成 Promise 就能开始受益。
常见错误是直接在 new Promise 里调用异步函数却不传 resolve/reject —— 这会导致 Promise 永远 pending。
- 用
new Promise((resolve, reject) => { ... })包裹老 API，比如setTimeout、XMLHttpRequest、Node.js 的fs.readFile - 确保每个分支都调用
resolve()或reject()，包括异常捕获块（try/catch内要显式reject(err)） - 不要在
then回调里再写回调：错例promise.then(() => setTimeout(() => {...}, 100))；应返回新 Promise：promise.then(() => new Promise(...))
为什么 async/await 比 .then() 更好读？
async/await 是 Promise 的语法糖，不是替代品。它不改变执行模型，但大幅降低心智负担——尤其在需要顺序等待多个异步操作时。
典型坑：忘记 await 导致变量拿到的是 Promise 实例而非实际值，后续操作报 undefined is not a function 类错误。
立即学习“Java免费学习笔记（深入）”；
-
await只能在async函数内使用；顶层 await 仅限 ES Module 环境（如type="module"的 script 或 Node.js >=14.8） - 多个并行请求用
Promise.all([p1, p2, p3])，别写成await p1; await p2; await p3（后者是串行） -
try/catch可捕获被 reject 的 Promise，但无法捕获未被 await 的 Promise 错误（会变成 unhandledrejection）
Promise.allSettled 和 Promise.all 到底该选谁？
区别不在“全成功”或“全结束”，而在于失败时的行为策略：Promise.all 遇第一个 reject 就中断并抛错；Promise.allSettled 必等全部完成，返回每个 Promise 的状态对象。
选错会导致流程意外终止或掩盖关键错误。比如批量上传文件，一个失败不该让其余全部丢弃，但登录鉴权失败必须立刻退出。
- 用
Promise.all当所有操作必须成功才继续（如：获取用户信息 + 获取权限列表 + 加载配置） - 用
Promise.allSettled当需汇总结果、容错处理或日志记录（如：向多个监控端点发送心跳） -
Promise.race适合超时控制：Promise.race([fetch(...), timeout(5000)])，但注意 race 后未完成的 Promise 仍会执行（只是你不再关心）
哪些 Promise 状态容易被忽略？
很多人只关注 fulfilled 和 rejected，但 pending 和隐式 rejected（未 catch）才是真正出问题的地方。
浏览器开发者工具里看不到 pending Promise 的堆栈，Node.js 中未处理的 rejection 会触发 unhandledRejection 事件——但默认不报错，直到进程退出前才警告。
- 永远给 Promise 链末尾加
.catch()或try/catch，哪怕只是console.error - 避免“忘记 return”：在
then里不 return 值，下一个then会收到undefined；不 return Promise，就无法链式等待 - 调试时用
Promise.resolve().then(() => console.trace())查看微任务队列中的执行顺序
