AngularJS中无需使用reject终止Promise链的原理与文档查询

首先得纠正一个小误解：你写的return $q(function () { return null; })核心不是返回null，而是创建了一个永远不会被决议（resolve/reject）的Promise——因为这个resolver函数里根本没调用传入的resolve或者reject方法！这才是它能跳过后续then/catch的关键。

为什么这招能中断Promise链？ #

Angular的$q虽然对齐了Promises/A+规范，但保留了一些自己的实现细节。根据$q的逻辑，当Promise链中的某个then/catch回调返回一个处于pending状态的Promise时，整个链会暂停，直到这个Promise被决议。如果这个Promise永远保持pending（就像你写的这个，没人去resolve它），那后续所有的then/catch回调就永远不会被触发——相当于把链“卡”在了这里，自然就跳过了后面的逻辑。

而Promises/A+规范确实没定义这种场景，因为规范只聚焦于“已决议的Promise”的处理流程，对于永远pending的情况，规范只说后续回调会等待，但没做强制约束，这属于实现的边界特性，刚好被你用来解决模态框的问题了。

结合$uibModal的场景拆解 #

你的这段代码设计得很巧妙：

$uibModal.open({ /* 模态框配置 */ })
  .result
  .catch(function () {
    // 模态框被取消时，返回一个永远pending的Promise
    return $q(function () { return null; });
  })
  .then(function () {
    // 只有模态框正常关闭时，这里才会执行
    return someAPIcall();
  })
  .catch(function () {
    // 只处理API调用的错误，不会捕获模态框取消的情况
  });

• 当模态框被取消，result Promise被reject，进入第一个catch，返回那个pending的Promise。此时后续的then和catch因为一直等这个Promise决议，永远不会执行，完美跳过了不需要的API调用和错误处理。
• 当模态框正常关闭，result被resolve，直接跳过第一个catch，进入then执行API调用，后面的catch只处理API抛出的错误，逻辑清晰又不用做复杂的错误值判断。

关于文档和注意事项 #

Angular官方文档里没有专门把这个当技巧列出来，但在$q的说明里明确提到：当then/catch回调返回一个Promise时，后续的回调会等待该Promise完成后再执行。这个技巧就是利用了“永远不完成的Promise会让后续回调永远等待”这个特性。

另外要注意：这种方式会留下一个永远pending的Promise，在一些对内存敏感的场景里，可能会被认为是内存泄漏（因为Promise会持有相关回调的引用）。如果你的应用有严格的内存要求，可能需要考虑用其他方式（比如用标记变量在then里判断是否执行后续逻辑），但大多数业务场景下，这个技巧是安全又省心的。

内容的提问来源于stack exchange，提问作者blah238