promise 是对异步操作状态的显式建模，具有 pending、fulfilled、rejected 三种不可逆状态；then/catch 返回新 promise 实现链式调用，统一错误处理，避免回调地狱。
Promise 不是语法糖，而是对异步操作状态的显式建模；它本身不“解决”回调地狱，但提供了链式、可组合的错误传播机制，让嵌套回调变成线性调用。
Promise 是什么：三个确定状态 + 一个 then 链入口
Promise 是一个表示异步操作最终完成或失败的对象。它内部有且仅有三种状态：pending（进行中）、fulfilled（成功）、rejected（失败），状态一旦改变就不可逆。
关键在于：then 和 catch 总是返回一个新的 Promise，这使得你能把多个异步步骤串成一条链，而不是一层套一层。
- 构造时必须传入一个执行器函数
(resolve, reject) => {...}，它会立即执行 -
resolve(value)触发fulfilled，后续then的第一个参数被调用 -
reject(reason)或抛出异常触发rejected，后续catch或then的第二个参数被调用 - 每个
then的返回值（无论是否是 Promise）都会被自动包装进新 Promise，实现“穿透”
对比 callback hell：嵌套 vs 链式
传统回调地狱典型场景：读文件 → 解析 JSON → 请求 API → 写日志。用纯回调写就是四层缩进，错误处理分散、复用困难、控制流难追踪。
立即学习“Java免费学习笔记（深入）”；
用 Promise 改写后，每个步骤只关心自己的输入输出，错误统一由末端 catch 捕获，且任意环节返回 Promise 都能自然接入下一流程。
fetch('/api/config.json')
.then(res => res.json())
.then(config => fetch(`/api/data?token=${config.token}`))
.then(res => res.json())
.then(data => console.log('done:', data))
.catch(err => console.error('Failed at any step:', err));
注意：then 中若返回普通值（如字符串、对象），下一个 then 会立刻收到它；若返回 Promise，则等待其 settle 后再继续 —— 这个规则是链式成立的基础。
常见误用：忘记 return、混用 callback 和 Promise、吞掉错误
很多“Promise 没生效”的问题其实源于写法松散：
- 在
then回调里没return异步操作（比如漏了return fetch(...)），导致后续then立即执行，拿到undefined - 在 Promise 链里又写
setTimeout或fs.readFile这类 callback API，却不把它包装成 Promise，造成控制流断裂 - 用了
then(success, fail)形式却没在fail里throw或return Promise.reject()，导致错误无法继续向下游传递 - 全局未监听
unhandledrejection事件，导致 rejected Promise 被静默丢弃（尤其在 Node.js 中）
Promise.all、Promise.race 等静态方法不是语法糖，而是并发语义的明确表达
Promise.all([p1, p2, p3]) 表示“全部完成才算成功”，任一失败则整体失败；Promise.race([p1, p2, p3]) 表示“谁先 settle 就用谁的结果”。它们让并行逻辑变得可读、可测、可取消（配合 AbortSignal）。
但要注意：Promise.all 在遇到 rejection 时会立即 reject，不会等其他 Promise 结束 —— 如果你需要“总是等完所有再汇总结果”，得自己用 Promise.allSettled。
真正容易被忽略的是：Promise 链的错误捕获是“单向向下”的，没有 try/catch 那种向上冒泡能力；一旦某个 catch 吃掉了错误又没重新 throw，后面所有 then 就会照常执行，可能引发意料之外的状态。
