Promise拒绝后链式调用后续Promise的最佳实践

问题场景 #

存在两个均返回Promise的函数 A 和 B，业务要求仅当A执行reject（拒绝）时才调用B，同时需要对两个Promise的成功、错误执行结果分别打印日志。

初版实现的问题 #

最开始写的线性Promise链代码如下：

const A = () => Promise.reject(true);
const B = () => Promise.resolve(true);

A()
  .then(() => {
    console.log('A success');
  })
  .catch(() => {
    console.log('A error');
    return B();
  })
  .then(() => {
    console.log('B success');
  })
  .catch(() => {
    console.log('B error');
  });

这个写法在A拒绝时可以正常运行，但当A成功resolve时，会额外输出一条B success日志。这是Promise线性链的默认特性：只要前序节点没有返回reject或者抛出异常，后续挂载的.then就会依次执行，和“仅A失败才执行B逻辑”的需求天然冲突。

你写的嵌套方案不是hack #

你自己调整后的嵌套写法如下：

const A = () => Promise.reject(true);
const B = () => Promise.resolve(true);

A()
  .then(() => {
    console.log('A success');
  })
  .catch(() => {
    console.log('A error');

    return B().then(() => {
      console.log('B success');
    });
  })
  .catch(() => {
    console.log('B error');
  });

很多人觉得Promise链必须全部平铺才是规范，其实是误区。这个嵌套写法完全符合Promise A+规范：在catch分支里返回B的子Promise链，B的成功逻辑只会在B执行时才触发，子链的异常会继续透传到外层的catch处理，逻辑完全严谨，根本不是取巧的hack。

通用最佳实践 #

针对这类“满足条件才执行下一个异步任务”的分支场景，有两种更易维护的实现方案：

• 优先使用async/await（行业通用首选方案）
  用类同步的语法写异步逻辑，分支判断和普通同步代码完全一致，不会出现线性链状态穿透的问题，可读性最高：

  async function executeTask() {
    try {
      await A();
      console.log('A success');
    } catch (aError) {
      console.log('A error');
      try {
        await B();
        console.log('B success');
      } catch (bError) {
        console.log('B error');
      }
    }
  }
  
  executeTask();
  

  代码逻辑和业务需求完全一一对应，后续如果要加C、D之类的条件分支，修改成本极低，也不容易出隐蔽的逻辑bug。
• 特殊标记区分链状态（仅适合极简单的平铺链场景）
  如果项目环境不支持async/await，又不想写嵌套，可以在A成功的分支返回一个唯一标记，后续链节点通过判断标记决定是否执行B的逻辑：

  const A_SUCCESS = Symbol('a executed successfully');
  A()
    .then(() => {
      console.log('A success');
      return A_SUCCESS;
    })
    .catch(() => {
      console.log('A error');
      return B();
    })
    .then(res => {
      if (res !== A_SUCCESS) {
        console.log('B success');
      }
    })
    .catch(err => {
      // 注意：这里需要额外判断错误来源是B还是其他节点，复杂场景不推荐
      console.log('B error');
    });
  

  这个方案需要额外维护标记，还要做错误来源甄别，代码冗余度高，容易出问题，除非有强诉求要写平链，否则不推荐。

选型建议 #

• 只要项目环境支持async/await，直接用async/await写分支异步逻辑，维护成本最低
• 环境不支持的话，直接用你写的嵌套子链方案即可，完全符合规范，没有任何问题
• 尽量不要用纯线性平铺的Promise链处理多分支异步逻辑，很容易因为状态穿透出现不符合预期的执行结果

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