Promise本身不改善异步，只是使错误处理、组合和时序控制更可预测；回调地狱中throw因调用栈断裂导致try/catch失效，而Promise将错误收敛至.catch()或await的try/catch中。
Promise 本身不改善异步，它只是让异步流程的错误处理、组合和时序控制变得可预测、可链式表达——而回调地狱的问题恰恰出在这些地方。
回调地狱里 throw 为什么抓不到错误
嵌套回调中抛出异常，会直接跳出当前函数，但外层回调并不在同一个调用栈中，try/catch 失效。浏览器或 Node.js 只能触发 uncaughtException 或 rejectionHandled 这类兜底事件，无法精准定位。
使用 Promise 后，所有异步错误都会收敛到 .catch() 或 await 的 try/catch 块中：
fetch('/api/user')
.then(res => res.json())
.then(data => {
if (!data.id) throw new Error('Invalid user');
return fetch(`/api/profile/${data.id}`);
})
.catch(err => console.error('统一处理：', err.message));
Promise.all 和 Promise.race 解决的是并发协调问题
多个异步任务需要“全部完成”或“首个响应”时，手写回调要自己维护状态计数器或标记位，极易出错（比如漏掉某次回调、重复 resolve）。
立即学习“Java免费学习笔记（深入）”；
Promise.all 自动等待所有 Promise 完成，任一 reject 就立即 reject；Promise.race 则只取第一个 settled 的结果：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
Promise.all([fetch('/a'), fetch('/b')])→ 两个请求都成功才继续，否则进.catch -
Promise.race([fetch('/fast'), timeout(5000)])→ 超时或接口先返回，谁快用谁
注意：Promise.all 在 Chrome 89+ 支持 Promise.allSettled，用于忽略单个失败继续收集结果。
async/await 不是语法糖那么简单
它把异步操作“看起来像同步”，但底层仍是 Promise 链。关键好处是调试体验提升：断点可以逐行停在 await 行，调用栈清晰；而回调里 debugger 往往跳来跳去，上下文丢失。
但要注意陷阱：
- 忘记
await导致返回Promise对象而非实际值 -
for...of遍历异步数组时没加await，变成并行而非串行 -
try/catch只捕获当前await的 rejection，不会跨await捕获后续错误
Promise 构造函数里的执行时机容易被误解
new Promise((resolve, reject) => { ... }) 中的函数是**立即执行**的（executor），不是等到 .then 才运行。这意味着：
- 副作用（如发起请求、修改全局变量）在 Promise 创建时就发生了
- 如果 executor 抛出同步错误，会自动转为 rejected Promise，等价于
reject(e) - 不要在 executor 里写异步逻辑却不调用
resolve或reject，会导致 Promise 永远 pending
真正难的从来不是怎么写 Promise，而是判断该不该封装、何时该退回到回调（比如流式数据、事件监听）、以及如何与 AbortController 配合做取消——这些边界问题，文档很少提，但线上故障常源于此。
