Promise 本身无中断机制，“Pending 中断”指返回永不 settled 的 Promise（如 new Promise(() => {})）使链式调用挂起，后续 then/catch/finally 均不执行；但该做法属黑盒技巧，推荐改用 throw 错误、标记对象或 async/await 显式控制流。
Promise 本身没有“中断”机制，返回一个 Pending 状态的 Promise 实例（即既不 resolve 也不 reject 的实例）确实能让链式调用“卡住”，但这不是标准意义上的“中断”，而是让后续 then 和 catch 永远得不到执行——因为它们依赖前一个 Promise 的状态变化。
什么是“Pending 中断”？
所谓“中途中断链式调用”，本质是让当前 Promise 链停止向下传递。由于 Promise 的 then 只在前一个 Promise settled（即变为 fulfilled 或 rejected）后才执行，所以只要返回一个永远不 settled 的 Promise，后续处理函数就不会触发。
如何创建一个永远 Pending 的 Promise？
最简单的方式是不调用 resolve 或 reject：
-
new Promise(() => {})—— 构造函数中不调用任何回调，它就永远停留在 pending - 注意：不能写成
new Promise(() => void 0)，这等价于没调用，但语义清晰更重要 - 避免使用
setTimeout(() => {}, Infinity)等伪技巧，不可靠且多余
实际应用中的典型写法
比如在条件判断中决定是否继续链式操作：
立即学习“Java免费学习笔记（深入）”；
someAsyncTask()
.then(data => {
if (shouldStopChain(data)) {
return new Promise(() => {}); // 链在此挂起
}
return processData(data);
})
.then(result => console.log('这行不会执行')); // ✅ 被阻断
注意：catch 也无法捕获这个 pending Promise，因为它从未 reject；同样，finally 也不会运行，除非该 Promise 最终 settled。
替代方案更推荐：显式控制流
用 pending “中断”是一种黑盒技巧，不利于调试和协作。更清晰的做法是：
- 用
throw抛出特定错误，后续catch判断并忽略 - 返回一个带标记的对象（如
{ skip: true }），在下一个then中提前return - 改用 async/await + if/else，逻辑更直白
Promise 链的设计初衷是表达异步流程，而非控制中断。强行用 pending 模拟中断，容易造成资源泄漏或难以排查的“静默挂起”。
