Promise 是解决回调地狱和统一异步错误处理的原生构造器，具有 pending/fulfilled/rejected 三种不可逆状态，通过 executor 函数、链式 then/catch 及微任务调度实现可靠异步流程控制。
Promise 是 JavaScript 中处理异步操作的标准化对象，它不是回调函数的语法糖，而是为了解决回调地狱和统一异步错误处理而设计的原生构造器。
Promise 的三种状态和基本用法
一个 Promise 实例只能处于 pending、fulfilled 或 rejected 之一，且状态不可逆。创建时必须传入一个执行器函数 executor，它接收 resolve 和 reject 两个函数作为参数：
const p = new Promise((resolve, reject) => {
setTimeout(() => {
if (Math.random() > 0.5) {
resolve('success');
} else {
reject(new Error('failed'));
}
}, 100);
});
注意：resolve 和 reject 只是函数名，不是关键字；调用它们时传入的值会成为后续 then 或 catch 的参数。
- 直接
return一个非 Promise 值（如字符串、数字），会被自动包装成Promise.resolve(value) - 如果
then回调中抛出异常或返回被拒绝的 Promise，链式调用会跳转到最近的catch或下一个then的第二个参数 -
Promise.resolve()和Promise.reject()是快捷创建已决议 Promise 的方式，常用于兼容同步/异步路径
链式调用多个异步操作的关键：每个 then 必须返回 Promise
链式调用的本质是“前一个 then 的返回值决定下一个 then 的输入”。如果中间某个 then 返回的是普通值（比如 return 'hello'），下一级 then 会立即以该值为参数执行；但如果返回的是 Promise，则会等待其 settled 后再继续。
立即学习“Java免费学习笔记（深入）”；
- 常见错误：在
then中只调用异步函数但没return它，导致链断裂，后续then立即执行并收到undefined - 正确写法必须显式
return fetch(...).then(...)或return new Promise(...) - 使用
async/await写法时，async函数默认返回 Promise，所以return await fn()和return fn()在链式中效果一致（但前者多一次 await，不必要）
例如顺序请求两个 API：
fetch('/api/user')
.then(res => res.json())
.then(user => fetch(`/api/posts?userId=${user.id}`))
.then(res => res.json())
.then(posts => console.log(posts))
.catch(err => console.error('链中任一环节失败：', err));
如何避免 catch 捕获不到错误？
catch 只能捕获前面 Promise 链中未被处理的 rejection。以下情况会导致错误“丢失”：
- 在
then(onFulfilled, onRejected)的第二个参数里吞掉了错误，但没重新抛出或返回拒绝态 Promise - 在
then回调内部抛出同步错误，但该then没提供onRejected参数，也未接catch - 使用了
Promise.all([p1, p2])但没处理其中某个子 Promise 失败（它会立刻 reject），应改用Promise.allSettled或提前包裹每个子 Promise
推荐统一收口错误的方式：
someAsyncTask()
.then(result => process(result))
.catch(error => {
// 所有链上未捕获的 rejection 都到这里
reportError(error);
throw error; // 如果还需继续传递，记得 re-throw
});
实际开发中最容易忽略的细节
Promise 链不是“线性执行流”，它的调度依赖微任务队列。这意味着：
-
then回调总是在当前同步代码执行完后、下一个宏任务前执行（即 microtask 阶段） - 多个独立 Promise 的
then不保证执行顺序，除非显式串行（如用await或链式then） -
Promise.resolve().then(() => console.log(1)); console.log(2);输出一定是2然后1，这个时序常被误判 - 调试时看不到“阻塞点”，需借助
console.time或 DevTools 的 async stack trace 查看真实调用链
真正难的不是写对语法，而是理解每个 return 和每个嵌套层级如何影响整个链的状态流转——尤其当混用 async/await 和原生 Promise 时，容易误以为 await 是“暂停”，其实它只是语法糖，底层仍是 Promise 链的延续。
