Promise 链的基本原理与组成
Promise 链的基本组成与 then、catch、finally 的关系
在一条 Promise 链中，每一个 then、catch、finally 都会返回一个新的 Promise，从而把异步操作串联起来。链的核心在于返回值的传递：前一个处理器的返回值会成为下一个处理器的输入，若返回的是 Promise，则进入新的异步阶段；若返回的是普通值，则继续在同一微任务队列中运行后续处理。理解这一点是掌握 Promise 链的基础。
当链中发生错误时，如果有 catch 来捕获，错误就会沿着链向后传播，直到遇到第一个能处理该错误的拒绝处理器为止。未捕获的错误会导致链条终止并进入浏览器的全局错误处理。
示例性代码展示了基本的链式结构与错误分支的走向：
Promise.resolve(1).then(v => v + 1).then(v => { console.log('step:', v); return v * 2; }).catch(err => { console.error('捕获到错误：', err); }).finally(() => { console.log('链条完成清理'); });
在实际中，finally 不关心链条的成功还是失败，它始终会执行，之后链条会继续向下传递原始的结果或错误，除非前续处理改变了状态。因此，合理使用 finally 可以确保资源清理的一致性。
返回值与链式调用的关系
每个 then() 都返回一个新的 Promise 实例，这使得多段异步操作可以通过简单的函数返回值进行串联。若 onFulfilled 返回一个值，下一步的处理将接收到这个值；若返回的是一个 Promise，链条会等待该 Promise 的完成再继续。
错误分支的设计要点：如果在某个 then 的回调中抛出异常或返回一个拒绝的 Promise，当前链路就会转入最近的拒绝处理器（catch），除非再有一个新的捕获处理后继续传播。这也是设计中断和控制流的重要手段。
代码示例：基本链路与错误传播的可视化
下面的示例演示了正常通过与错误捕获的传播路径，帮助理解在 catch 之后如何影响后续 then 的执行。
Promise.resolve('start').then(v => {console.log('第一步', v);return v + '-A';}).then(v => {console.log('第二步', v);// 这里主动抛错，模拟错误场景throw new Error('Something went wrong');}).catch(err => {console.error('捕获到错误', err.message);// 处理后决定是否继续链路return ' recovered';}).then(v => {console.log('继续链路的值：', v);}).catch(err => {console.error('最终未处理的错误', err.message);});
在 catch 之后如何中断后续 then 的执行？
思路：抛出新错误来阻断
核心要点在于在 catch 中再抛出一个错误，让后续的 then 遇到拒绝状态而跳转到最近的 catch 来处理。如果你不希望后续 then 执行，就需要通过抛错或返回一个拒绝的 Promise。这实际上等价于在不希望继续执行的情况下明确结束当前链路的信号。
示例要点说明：在 catch 内返回 Promise.reject(...) 或直接 throw 新错误，后续的 then 将不会执行，除非有新的 catch 捕获该错误，否则链路会进入未处理的拒绝状态。这是在前端开发中最常用的“中断方式”。
需要注意的是，如果 catch 之后紧跟着一个同级的 then，在未抛出错误的情况下该 then 仍然会执行；因此要真正中断，务必在 catch 中引发新的错误或返回拒绝的 Promise。
具体代码演示
演示1：在 catch 里抛出错误，中断后续 then 的执行，并通过下一个 catch 捕获最终错误。
Promise.resolve().then(() => {console.log('先执行');}).then(() => {console.log('会执行吗？');}).catch(e => {console.error('捕获到错误', e);// 中断后续执行：重新抛出throw new Error('中断链路');})// 下面的 then 不会执行，会跳转到这里的 catch.then(() => {console.log('这段不会执行');}).catch(e => {console.error('最终捕获到的错误', e.message);});
演示2：返回拒绝的 Promise 也能实现同样的中断效果，效果与上例等价，但风格略有不同。关键是避免后续 then 捕获不到错误而误以为链继续。
Promise.resolve().then(() => {console.log('起始');}).then(() => {console.log('继续执行');}).catch(e => {console.error('处理错误', e);return Promise.reject(new Error('链路被拒绝'));}).then(() => {// 这段不会执行console.log('不应该出现');}).catch(e => {console.error('最终捕获', e.message);});
原理解析：Promise 链中的错误传播与中断机制
微任务队列与 then 的执行时序
Promise 的回调执行属于微任务，当 Promise 状态改变后，相关的 then/catch 回调会被放入微任务队列，在当前事件循环结束后统一执行。这使得错误在链中的传播具有确定性，即一旦进入拒绝分支，后续的处理就会按设定的捕获顺序继续推进或中断。
理解这一点有助于排查异步逻辑中的时序问题，特别是在复杂链路中，某一个 catch 的行为会直接影响后续 then 的执行。不要低估微任务队列对链式错误处理的影响。
异常传播路径与后续 then 的执行
错误沿着 then/catch 链向后传播，直到被最近的捕获处理器吃掉；如果 catch 处理后重新抛出错误，链路就会跳转到下一个可用的 catch，若没有合适的 catch，错误将成为未捕获的拒绝，影响应用稳定性。
因此，在设计 Promise 链时，需要清晰地定义每个 catch 的职责范围，避免将错误“吞掉”后导致后续逻辑不按预期执行。
最终的错误传播与浏览器行为
不同浏览器对未捕获的拒绝可能有不同的提示，但基本原则是一致的：未捕获的拒绝会导致全局错误处理器触发。在生产环境中，务必通过链路中的 catch 完成显式的错误处理，以提升稳定性。
前端实战要点
在前端项目中的应用示例
实际开发中，你可能需要在一次网络请求失败后迅速中断后续的展示逻辑，或者在某种条件下阻断后续数据处理。通过在 catch 内部抛错或返回拒绝 Promise，可以实现可控的中断行为，从而避免在用户体验上产生错误的连锁反馈。
示例场景：一个串行的数据获取流程，若某一步失败就不继续请求后续数据，保持 UI 的一致性与错误信息的清晰。
async/await 与 Promise 链的对比
在很多场景下，async/await 提供了更直观的错误处理方式，你仍然可以借助 try/catch 来中断或跳转逻辑；但底层仍是 Promise 链，理解其行为对调试和优化很重要。异步控制的本质没有改变，只是表达方式更简洁。
async function loadData() {try {const a = await fetch('/api/a');const b = await fetch('/api/b'); // 若 a 失败，b 将不会执行} catch (err) {// 处理错误，决定是否继续后续逻辑throw err; // 或者返回某个值，视需求而定}
}
调试与测试要点
使用调试工具时，关注 then/catch 的执行顺序，在断点处观察返回值、错误信息以及 next promise 的状态。为复杂链添加单元测试，覆盖正常流、错误流与中断场景，能显著提高代码鲁棒性。
在测试中，模拟网络错误、超时和手动抛错等场景，确保 catch 能处理并且在需要时正确中断后续的 then。
