Promise状态管理：从原理到避坑
先搞懂：Promise的”三态密码”为啥这么重要
你可能听过Promise有pending、fulfilled、rejected三种状态，但你知道为啥状态一旦变了就再也改不回去吗？这可不是随便设计的——就像点外卖，下单后是”配送中”(pending)，送到了就是”已完成”(fulfilled)，丢了就是”已取消”(rejected)，总不能说外卖送到了又变回配送中吧？这种”状态不可逆”的特性，其实是为了保证异步操作结果的唯一性。我之前接过一个老项目，前同事用变量手动标记异步状态，结果多个地方同时修改那个变量，导致页面时而显示加载中，时而显示数据，最后排查半天才发现是状态被篡改了。而Promise从设计上就杜绝了这种问题：一旦从pending变成fulfilled或rejected，就像泼出去的水，再也变不回来。
那状态具体咋转换的呢？咱们用个表格直观看看：
| 初始状态 | 触发条件 | 最终状态 | 结果值 |
|---|---|---|---|
| pending | 调用resolve(value) | fulfilled | value（成功结果） |
| pending | 调用reject(reason) | rejected | reason（错误信息） |
| fulfilled | 再次调用resolve/reject | 保持fulfilled | 原value不变 |
这里有个细节你得注意：Promise构造函数里的 executor 函数是同步执行的，而 then 方法里的回调是异步执行的。我之前就踩过坑——以为 then 里的代码会马上执行，结果在里面获取DOM元素时总拿不到，后来才反应过来：new Promise的时候 executor 同步跑，但 then 回调要等当前同步代码跑完才进微任务队列。这一点在调试状态问题时特别关键，你可以在代码里加 console.log 看看执行顺序，保证能让你对”异步”有更深的理解。
状态管理最容易踩的三个坑，我替你踩过了
哪怕懂了原理，实际写代码时还是容易出问题。去年带团队做一个电商项目，有个模块需要先调用户信息接口，再调购物车接口，结果测试时总出现购物车数据偶尔加载不出来的情况。查了半天发现，是同事在用户信息接口的 then 回调里，又嵌套了一个 new Promise，而且没处理 reject 状态，导致一旦用户信息接口失败，整个链条就断了，购物车代码根本不执行。这就是典型的”状态依赖混乱”——你得记住，每个Promise都是独立的状态机，依赖其他Promise状态时，一定要显式处理所有可能的状态。
另一个常见坑是”重复 resolve/reject”。我见过有人为了保险，在Promise里写”如果A条件满足就resolve，否则如果B条件满足也resolve”，结果两种条件同时满足时，代码会执行两次 resolve。但前面说了，状态不可逆，第二次 resolve 其实是无效的，只会浪费性能。正确的做法是用 if-else 明确分支，或者用 return 提前退出，比如：
new Promise((resolve, reject) => {
if (conditionA) {
resolve(resultA);
return; // 避免继续执行下面的代码
}
if (conditionB) {
resolve(resultB);
return;
}
reject(new Error('条件不满足'));
});
还有个隐蔽的坑是”状态判断错误”。比如以为只要Promise执行完就是 fulfilled 状态，但 如果你在 then 回调里 throw 错误，或者 return 一个 rejected 的Promise，那这个 then 返回的新Promise会变成 rejected 状态。我之前就因为这个，在链式调用里判断状态时出过错——以为前一个 then 成功了，结果里面有个隐藏的错误，导致下一个 then 根本没执行。所以调试时，除了看当前Promise的状态，还要检查整个链条上每个环节的返回值。
Promise错误处理与实战：从”捕获”到”优雅解决”
错误处理：reject、catch和try/catch咋选？
聊完状态，就得说最让人头疼的错误处理了。很多人分不清 reject 回调和 catch 方法的区别，其实简单说：reject 是Promise内部主动抛出错误的方式，而 catch 是捕获错误的”安全网”。比如你写 new Promise((resolve, reject) => { reject('错了') })，这是主动 reject；而 .then(res => {}, err => {}) 里的第二个参数是处理 reject 的回调，.catch(err => {}) 则是专门捕获错误的。
但这里有个关键区别：then 的第二个回调只能捕获当前Promise的 reject 错误，而 catch 能捕获整个链式调用中前面所有Promise的错误。举个例子，如果你写 promiseA.then(res => promiseB).then(res => {}, err => {})，这里的 err 回调只能捕获 promiseB 的错误，抓不到 promiseA 的错误；但如果改成 promiseA.then(res => promiseB).catch(err => {})，不管是 promiseA 还是 promiseB 出错，都会被 catch 捕获。所以我通常 用 catch 统一处理错误，除非你需要对不同环节的错误做差异化处理。
还有个容易忽略的点：Promise的错误会”冒泡”。就像水里冒泡一样，链条中任何一个环节出错，都会一直往后冒，直到被 catch 捕获。去年做一个数据可视化项目，需要依次调用三个接口处理数据，结果第二个接口偶尔返回格式错误，导致整个链条卡住。后来在链条最后加了个 catch，不仅捕获了错误，还能拿到具体是哪个接口出的问题——因为错误对象里会保留堆栈信息。所以写链式调用时，一定要在最后加 catch，别让错误”裸奔”。
三个实战案例，帮你把Promise用出花
光说不练假把式，咱们结合实际场景看看怎么用Promise解决问题。
案例1：并行请求控制
比如你需要同时调3个独立的接口（比如商品列表、分类、轮播图），等所有接口都返回后再渲染页面。这时候用 Promise.all 最合适，但有个坑：Promise.all 只要有一个Promise reject，整个就会立即 reject，其他接口的结果也拿不到。如果你的场景允许部分接口失败，比如轮播图接口挂了，但商品列表和分类还能显示，那就得用 Promise.allSettled，它会等所有Promise都结束（不管成功失败），返回每个Promise的状态和结果。我之前帮一个资讯网站做优化，就把首页的5个并行接口从 Promise.all 改成了 Promise.allSettled，页面加载成功率从85%提到了99%，因为就算某个非关键接口失败，其他内容照样能显示。
案例2：接口依赖处理
电商项目里常见”先调用户信息接口，拿到用户ID后，再调订单列表接口”的场景。这时候用链式调用：
getUserInfo()
.then(user => getUserOrders(user.id))
.then(orders => renderOrders(orders))
.catch(err => {
console.error('加载失败:', err);
showErrorToast('数据加载失败，请重试');
});
但这里要注意，如果 getUserInfo 成功但 getUserOrders 失败，catch 会捕获到错误。如果需要更精细的控制，比如用户信息接口失败显示”请登录”，订单接口失败显示”获取订单失败”，可以在每个 then 里单独处理错误：
getUserInfo()
.then(user => {
return getUserOrders(user.id).catch(err => {
showErrorToast('获取订单失败');
throw err; // 继续抛出错误，让外层catch处理后续逻辑
});
})
.then(orders => renderOrders(orders))
.catch(err => {
if (err.message.includes('用户信息')) {
showErrorToast('请先登录');
}
});
案例3：超时中断请求
有时候接口响应太慢，需要超时自动取消。这时候可以用 Promise.race——让你的请求Promise和一个超时Promise赛跑，谁先结束就用谁的结果。比如：
function fetchWithTimeout(url, timeout = 5000) {
const request = fetch(url);
const timeoutPromise = new Promise((_, reject) => {
setTimeout(() => reject(new Error('请求超时')), timeout);
});
return Promise.race([request, timeoutPromise]);
}
// 使用
fetchWithTimeout('https://api.example.com/data')
.then(res => res.json())
.catch(err => {
if (err.message === '请求超时') {
showErrorToast('网络较慢，请稍后再试');
}
});
这个方法我在多个项目里用过，特别是移动端，用户网络环境复杂，超时处理能极大提升体验。
最后再补充个结合 async/await 的小技巧：虽然 async/await 让代码更像同步，但本质还是Promise，所以错误处理要用 try/catch。我习惯把 await 调用放在 try 里，catch 里处理错误，比如：
async function loadData() {
try {
const user = await getUserInfo();
const orders = await getUserOrders(user.id);
renderOrders(orders);
} catch (err) {
console.error('加载失败:', err);
showErrorToast('数据加载失败');
}
}
但要注意，await 只能捕获它后面那个Promise的错误，如果有多个 await，前面的成功后面的失败，也会被 catch 捕获，这点和Promise链式调用的错误冒泡类似。
现在你应该对Promise的状态管理和错误处理有比较清晰的认识了。其实核心就两点：理解每个Promise的状态是独立且不可逆的，以及永远不要假设异步操作一定成功。你可以试试用今天说的方法，重构一下你项目里的异步代码，特别是那些嵌套了多层回调的部分，相信你会发现代码清爽多了。如果试了有效果，或者遇到新问题，欢迎回来一起讨论！
参考资料：
咱们先看then方法的第二个回调函数啊，它就像个“局部保安”，只能管自己眼前那一片。比如说你写了个链式调用：promiseA.then(res => promiseB).then(res => {}, err => {})，这里第二个then的err回调，就只能盯着promiseB的状态——要是promiseB rejected了，它能接住；但如果是promiseA先出了错，比如接口404了，这个err回调根本看不见，错误就直接“溜走”了，跟没处理一样。我之前帮同事查bug，他就犯过这错，以为每个then都加了err回调就安全了，结果最前面的promise出错时，整个链条直接卡住，控制台报错都找不到在哪儿抛的。
那catch方法就不一样了，它像个“全局保安队长”，能管整条链式调用的安全。不管是第一个promise reject了，还是中间某个then回调里不小心throw了个错误，甚至是return了一个rejected的新promise，catch都能一揽子接住。举个实际场景，你调用户信息接口，然后用用户ID调订单接口，再用订单ID调详情接口，这一串下来，随便哪个环节出错，最后加个.catch(err => {})，都能把错误抓住。而且catch还能拿到错误堆栈，告诉你具体是哪个环节出了问题，调试起来一目了然。不过也不是说then的第二个回调就没用——如果某个中间环节的错误需要特殊处理，比如用户信息接口失败要提示“请登录”，订单接口失败要提示“网络异常”，这时候用then的第二个回调单独处理，再把错误继续抛给catch处理后续逻辑，就很灵活。但大多数时候，我还是推荐在链式调用最后加个catch，相当于给整个异步流程加了道“安全网”，总比错误漏处理导致页面卡死强。
Promise有哪三种状态？它们有什么重要特点？
Promise包含pending（进行中）、fulfilled（已成功）和rejected（已失败）三种状态。初始状态为pending，当调用resolve()时转为fulfilled，调用reject()时转为rejected。最关键的特点是状态不可逆，一旦从pending变为fulfilled或rejected，就无法再变回其他状态，这保证了异步操作结果的唯一性，避免状态被重复修改导致逻辑混乱。
then方法的第二个回调和catch方法处理错误有什么区别？
then方法的第二个回调（如.then(res => {}, err => {})）只能捕获当前Promise的rejected状态错误；而catch方法（如.catch(err => {})）能捕获整个链式调用中前面所有Promise的错误，包括then回调中抛出的异常。实际开发中， 优先使用catch统一捕获错误，除非需要对不同环节的错误做差异化处理。
Promise.all和Promise.allSettled在使用时有什么不同？
Promise.all接收一个Promise数组，只有当所有Promise都fulfilled时才返回结果数组，若有一个Promise rejected则立即整体rejected，适合需要全部成功的场景（如页面初始化需加载多个关键资源）。Promise.allSettled则会等待所有Promise都结束（无论成功或失败），返回每个Promise的状态和结果（{status: ‘fulfilled’, value}或{status: ‘rejected’, reason}），适合允许部分接口失败的场景（如非关键数据加载）。
为什么Promise的状态一旦改变就不能再修改？
Promise状态不可逆是为了保证异步操作结果的确定性。就像现实中点外卖，“配送中”（pending）状态一旦变为“已送达”（fulfilled）或“已取消”（rejected），就不可能再回到“配送中”。这种设计避免了多线程或多任务同时修改状态导致的逻辑混乱，确保异步操作的结果唯一且可预测，从根本上解决了手动管理状态变量时容易出现的“状态篡改”问题。
使用async/await时如何处理Promise的错误？
async/await本质是Promise的语法糖，错误处理需结合try/catch语句。将await调用的Promise放在try块中，若Promise rejected，错误会被catch块捕获。例如：try { const res = await fetchData(); } catch (err) { console.error('请求失败:', err); }。这种方式能清晰捕获await链中的所有错误，且代码结构更接近同步逻辑，适合处理接口依赖等复杂异步场景。
