Promise 扁平化嵌套靠。then()返回新 Promise 而非嵌套调用；串行需显式 return 并传递参数；Promise.all/race 解决并行非串行；避免在。then 中新建 Promise 或包裹同步逻辑。
Promise 怎么扁平化嵌套回调
Promise 本身不“解决”回调地狱，它提供了一种链式写法让嵌套变平——关键在 .then() 返回新 Promise，而不是在上一个 .then() 里再写 .then()。
常见错误是仍把异步操作塞进 回调函数 体里，比如：
fetch('/api/a') .then(res => res.json()) .then(data => {fetch('/api/b?x=' + data.id) // ❌ 忘记 return，这里返回的是 undefined .then(r => r.json()) .then(d => console.log(d)); });正确做法是显式 return 下一个 Promise：
- 每个
.then()回调里，若要继续链式调用，必须return一个 Promise（或可被Promise.resolve()包装的值） - 不 return 就断链，后续
.then()会立即收到undefined - 同步异常（如
throw new Error()）会被自动捕获进下一个.catch()，不用手动reject()
多个 异步任务 怎么串行执行而不嵌套
串行即“等前一个完成再发起下一个”，典型场景是分页拉取、依赖上一步结果的 API 调用。直接用 async/await 最直观，但纯 Promise 也能做到：
立即学习“Java 免费学习笔记（深入）”；
Promise.resolve() .then(() => fetch('/api/user')) .then(res => res.json()) .then(user => fetch('/api/posts?uid=' + user.id)) .then(res => res.json()) .then(posts => console.log(posts)) .catch(err => console.error(err));注意点：
- 起手用
Promise.resolve()统一入口，避免第一个fetch出错时无法被最外层.catch()捕获 - 不要写成
fetch().then(() => fetch())，这会丢失第一个请求的响应数据；应靠参数传递（如上例中user） - 如果某步需要并行发起多个请求（如同时拉用户和配置），就别硬串，改用
Promise.all([p1, p2])
Promise.all 和 Promise.race 的误用场景
这两个方法常被拿来“替代回调地狱”，但它们解决的是不同问题：Promise.all 是并行 + 全成功，Promise.race 是竞速，都不等于“链式流程控制”。
典型误用：
- 用
Promise.all([fetch('/a'), fetch('/b')])去处理有依赖关系的任务（比如 b 需要 a 的返回 id）→ 应该串行，不是并行 - 用
Promise.race([timeout(), apiCall()])但没给timeout()加reject→race只取第一个 settle 结果，如果 timeout 永不 reject，就会永远卡住 -
Promise.all中任意一个 reject，整个就失败；若想“全部执行完，不管成败”，得用Promise.allSettled（注意兼容性）
为什么 用了 Promise 还有“地狱感”
常见原因不是 Promise 不好用，而是没切断旧习惯：
- 在
.then()里又写一层new Promise((resolve, reject) => {……})→ 其实多数时候可以直接return fetch(……) - 错误地把同步逻辑（如数据转换）包进
setTimeout或额外 Promise → 同步代码不需要 Promise 包裹 - 过度拆分
.then()，比如每个字段提取都单独写一行.then(x => x.data).then(y => y.items)，反而增加阅读负担
真正难的不是语法，是区分哪些操作天然异步（API、定时器、文件读取）、哪些只是同步计算——后者不该进 Promise 链。
