使用一个和另一个没有任何优势，但是，有一种特定的情况是throw行不通的。但是，这些情况可以修复。

任何时候在 promise 回调中，都可以使用throw. 但是，如果您处于任何其他异步回调中，则必须使用reject.

例如，这不会触发捕获：

new Promise(function() {
  setTimeout(function() {
    throw 'or nah';
    // return Promise.reject('or nah'); also won't work
  }, 1000);
}).catch(function(e) {
  console.log(e); // doesn't happen
});

相反，您会留下一个未解决的Promise和一个未捕获的异常。在这种情况下，您希望改为使用reject. 但是，您可以通过两种方式解决此问题。

1. 通过在超时内使用原始 Promise 的拒绝函数：

new Promise(function(resolve, reject) {
  setTimeout(function() {
    reject('or nah');
  }, 1000);
}).catch(function(e) {
  console.log(e); // works!
});

2. 通过Promise超时：

function timeout(duration) { // Thanks joews
  return new Promise(function(resolve) {
    setTimeout(resolve, duration);
  });
}

timeout(1000).then(function() {
  throw 'worky!';
  // return Promise.reject('worky'); also works
}).catch(function(e) {
  console.log(e); // 'worky!'
});

另一个重要的事实是，reject() 并不像一个终止控制流return语句一样。相反，throw确实会终止控制流。

例子：

new Promise((resolve, reject) => {
  throw "err";
  console.log("NEVER REACHED");
})
.then(() => console.log("RESOLVED"))
.catch(() => console.log("REJECTED"));

对比

new Promise((resolve, reject) => {
  reject(); // resolve() behaves similarly
  console.log("ALWAYS REACHED"); // "REJECTED" will print AFTER this
})
.then(() => console.log("RESOLVED"))
.catch(() => console.log("REJECTED"));

是的，最大的区别是拒绝是在Promise被拒绝后执行的回调函数，而throw不能异步使用。如果您选择使用拒绝，您的代码将继续以异步方式正常运行，而throw将优先完成解析器功能（此功能将立即运行）。

我看到的一个帮助我澄清问题的示例是，您可以使用拒绝设置超时函数，例如：

new Promise((resolve, reject) => {
  setTimeout(()=>{reject('err msg');console.log('finished')}, 1000);
  return resolve('ret val')
})
.then((o) => console.log("RESOLVED", o))
.catch((o) => console.log("REJECTED", o));

上面不可能用 throw 写。

try{
  new Promise((resolve, reject) => {
    setTimeout(()=>{throw new Error('err msg')}, 1000);
    return resolve('ret val')
  })
  .then((o) => console.log("RESOLVED", o))
  .catch((o) => console.log("REJECTED", o));
}catch(o){
  console.log("IGNORED", o)
}

在 OP 的小示例中，无法区分的差异但是在处理更复杂的异步概念时，两者之间的差异可能很大。

TLDR： 当函数有时返回Promise有时抛出异常时，它很难使用。编写异步函数时，更喜欢通过返回被拒绝的Promise来表示失败

您的特定示例混淆了它们之间的一些重要区别：

因为您在Promise链中进行错误处理，所以抛出的异常会自动转换为被拒绝的Promise。这可以解释为什么它们似乎可以互换——它们不是。

考虑以下情况：

checkCredentials = () => {
    let idToken = localStorage.getItem('some token');
    if ( idToken ) {
      return fetch(`https://someValidateEndpoint`, {
        headers: {
          Authorization: `Bearer ${idToken}`
        }
      })
    } else {
      throw new Error('No Token Found In Local Storage')
    }
  }

这将是一种反模式，因为您将需要同时支持异步和同步错误情况。它可能看起来像：

try {
  function onFulfilled() { ... do the rest of your logic }
  function onRejected() { // handle async failure - like network timeout }
  checkCredentials(x).then(onFulfilled, onRejected);
} catch (e) {
  // Error('No Token Found In Local Storage')
  // handle synchronous failure
} 

不好，这正是Promise.reject（在全局范围内可用）可以解决问题并有效地将其与throw. 重构现在变成：

checkCredentials = () => {
  let idToken = localStorage.getItem('some_token');
  if (!idToken) {
    return Promise.reject('No Token Found In Local Storage')
  }
  return fetch(`https://someValidateEndpoint`, {
    headers: {
      Authorization: `Bearer ${idToken}`
    }
  })
}

这现在允许您仅使用一个catch()来处理网络故障和缺少令牌的同步错误检查：

checkCredentials()
      .catch((error) => if ( error == 'No Token' ) {
      // do no token modal
      } else if ( error === 400 ) {
      // do not authorized modal. etc.
      }

有一个区别 - 这应该无关紧要 - 其他答案没有涉及，所以：

如果执行处理程序传递给thenthrows，则该调用返回的Promise将then被抛出的内容拒绝。

如果它返回一个被拒绝的Promise，调用返回的Promise将then被解析为该Promise（并且最终将被拒绝，因为它被解析为的Promise被拒绝），这可能会引入一个额外的异步“滴答”（在微任务队列，用浏览器术语来说）。

但是，任何依赖于这种差异的代码都从根本上被破坏了。:-) 它不应该对Promise结算的时间那么敏感。

下面是一个例子：

function usingThrow(val) {
    return Promise.resolve(val)
        .then(v => {
            if (v !== 42) {
                throw new Error(`${v} is not 42!`);
            }
            return v;
        });
}
function usingReject(val) {
    return Promise.resolve(val)
        .then(v => {
            if (v !== 42) {
                return Promise.reject(new Error(`${v} is not 42!`));
            }
            return v;
        });
}

// The rejection handler on this chain may be called **after** the
// rejection handler on the following chain
usingReject(1)
.then(v => console.log(v))
.catch(e => console.error("Error from usingReject:", e.message));

// The rejection handler on this chain may be called **before** the
// rejection handler on the preceding chain
usingThrow(2)
.then(v => console.log(v))
.catch(e => console.error("Error from usingThrow:", e.message));

如果你运行它，在撰写本文时，你会得到：

使用抛出错误：2 不是 42！
usingReject 错误：1 不是 42！

注意顺序。

将其与相同的链进行比较，但都使用usingThrow：

function usingThrow(val) {
    return Promise.resolve(val)
        .then(v => {
            if (v !== 42) {
                throw new Error(`${v} is not 42!`);
            }
            return v;
        });
}

usingThrow(1)
.then(v => console.log(v))
.catch(e => console.error("Error from usingThrow:", e.message));

usingThrow(2)
.then(v => console.log(v))
.catch(e => console.error("Error from usingThrow:", e.message));

这表明拒绝处理程序以其他顺序运行：

使用抛出错误：1 不是 42！
使用抛出错误：2 不是 42！

我在上面说“可能”是因为在其他领域有一些工作在其他类似情况下删除了这种不必要的额外勾选，如果涉及的所有Promise都是本机Promise（不仅仅是 thenables）。（特别是：在一个async函数中，return await x最初引入了一个额外的异步滴答，return x而其他方面是相同的；ES2020 对其进行了更改，以便如果x是本机Promise，则在没有其他区别的情况下删除额外的滴答。）

同样，任何对Promise的结算时间如此敏感的代码都已经被破坏了。所以真的不重要/不应该重要。

实际上，正如其他答案所提到的：

• 正如凯文 B 指出的那样，throw如果您正在回调到您在履行处理程序中使用的某个其他函数，则将无法工作——这是最大的问题
• 正如lukyer 指出的那样，throw突然终止该函数，这可能很有用（但您return在示例中使用的是相同的功能）
• 正如Vencator 所指出的，您不能throw在条件表达式 ( ? :) 中使用，至少现在不能

除此之外，这主要是风格/偏好问题，因此与大多数风格/偏好一样，与您的团队达成一致（或者您不关心任何一种方式），并保持一致。