Promise 是 JavaScript 异步编程的契约机制，以不可逆的 pending/fulfilled/rejected 状态封装异步结果，支持链式消费但不消除嵌套；需配合 Promise.all、async/await 等组合降噪，避免手动 new Promise 和竞态问题。
Promise 不是语法糖，它是 JavaScript 异步编程的契约机制——用状态（pending/fulfilled/rejected）替代嵌套回调，但直接 new Promise(...) 写多了反而更难维护。
Promise 是什么：一个有状态、不可逆、可链式消费的异步容器
它不是“让异步变同步”的工具，而是一个标准化的异步结果封装：一旦进入 fulfilled 或 rejected 状态，就不可更改；后续所有 .then() 或 .catch() 都只能消费这个终态结果。
- 构造时必须传入一个执行器函数，该函数立即执行，并接收
resolve和reject两个函数参数 -
resolve(value)触发fulfilled，reject(reason)触发rejected；注意：reject不等于throw，但throw在执行器中会隐式调用reject -
.then()总是返回一个新的 Promise，所以能链式调用；但它的两个参数（onFulfilled/onRejected）都只接收上一级的终值或原因，不自动透传错误
为什么 .then().catch() 不能完全替代 try/catch？
因为 Promise 链中的错误捕获是“单向向下”的：上层 .catch() 只能捕获它之前（包括同级 .then() 中抛出的错误），无法捕获之后新创建的 Promise 的异常。
- 常见误写：
promise.then(...).catch(...).then(...)—— 最后一个.then()抛错不会被前面的.catch()捕获 - 正确做法：每个可能出错的异步操作后紧跟自己的
.catch()，或统一在链末尾加.catch()（但要确保链不被意外中断） - 更稳妥的方式是用
async/await配合try/catch，因为 await 会把 rejected Promise 转为同步抛错
如何真正解决回调地狱：别只盯着 Promise 构造，重点在组合与降噪
回调地狱的本质是控制流混乱 + 错误路径分散。Promise 本身不消除嵌套，Promise.all()、Promise.race()、async/await 才是破局点。
立即学习“Java免费学习笔记（深入）”；
- 多个无关请求并行？用
Promise.all([p1, p2, p3])，任一失败则整体 reject；需要容错就先用.catch(() => null)包装每个 Promise - 依赖顺序的串行调用？避免手写
p1.then(() => p2).then(() => p3)，改用async/await更直白：const a = await apiA();
const b = await apiB(a);
const c = await apiC(b); - 仍需手动 new Promise？大概率是你在封装老式回调 API（如 Node.js 的
fs.readFile），这时应优先使用现成的fs.promises或util.promisify()，而非重复造轮子
容易被忽略的坑：Promise 状态一旦 settled 就无法再触发回调
这导致两个典型问题：缓存失效和竞态条件。
- 反复调用同一个 Promise 实例（比如
const p = fetch(...); p.then(...); p.then(...)）没问题，但若误以为重新.then()会重发请求——不会，它只是复用已 settle 的结果 - 多个异步操作竞争同一资源（如搜索框频繁输入），旧请求的 Promise 若比新请求先 resolve，就会覆盖 UI；必须在 then 中校验当前是否仍是最新请求（例如比对 request id 或 abortController.signal）
- 未处理的 rejection 会触发
unhandledrejection事件，在生产环境务必监听并上报，否则静默失败
