>Story
在我的一生中，我一直在我的承诺中使用以下代码模式：
const => new Promise((resolve, reject) => {
//do some work
if(err !== undefined){
reject(err);
return;
}
if(someCondition){
resolve(1);
return;
}
resolve(2);
});
然而，最近我的一个学生向我展示了一个有趣的代码：
const => new Promise((resolve, reject) => {
//do some work
if(err !== undefined) return reject(err);
if(someCondition) return resolve(1);
resolve(2);
});
我的第一反应是：">你应该按照我的方式做，因为......(随后沉默)">
问题
我试图为差异找到一个合乎逻辑的解释，但我找不到。
我尝试检查 MDN 文档中的承诺，看看解析或拒绝是否可以返回除undefined以外的内容，但我也没有找到它。
问题：
所以现在我只剩下一个问题： - 我的方法和学生的方法(如果有的话)有什么区别，代码功能方面？(AKA，它们是否总是返回相同的输出并在相同的条件下具有相同的行为？
我的方法和学生的方法(如果有的话)有什么区别(如果有的话)，代码功能方面？
在这种特定情况下，没有任何，原因有三：
-
传递给 Promise 执行器(您传递给
new Promise的函数)的resolve和reject函数被定义为返回undefined。因此，return resolve(...)实际上是resolve(...); return undefined; -
Promise 构造函数不使用执行器的返回值，因此即使 #1 不为 true，它仍然无关紧要。
-
在函数中，
return;和return undefined;之间的差异存在于规范级别，但在代码中不可观察到。也就是说，在代码中，它们执行完全相同的操作，即使规范对它们略有不同。
可能值得注意的是，虽然它不会产生功能差异，但它会产生语义差异。return resolve(...)说"调用resolve并返回其返回值" ——这表明该返回值对代码有意义和重要。它没有，所以return resolve(...)误导人们稍后维护代码。作为风格问题，我不推荐它。(请注意，如果它变得足够普遍，它就会变成一个成语，并且通过了解成语来解决混乱，但是......如果保存行对你很重要，那就resolve(...); return;(或者更好的是，不要担心额外的行，或者让你的逻辑根本不需要return)。但是您的问题是关于功能的差异，所以...
推广到其他情况是危险的，在这些情况下，您调用的函数可能不会返回undefined，或者使用函数的返回值。
它们的行为方式始终完全相同，是的，因为传递给执行器的resolve和reject函数都返回undefined，return undefined等效于return(并且 promise 构造函数无论如何都不会使用您返回的值)。
不过，通常，您根本不想使用Promise构造函数。这个看起来像可以利用Promise.resolve和Promise.reject的东西，例如：
// do some work
if (err !== undefined) {
return Promise.reject(err);
}
if (someCondition) {
return Promise.resolve(1);
}
return Promise.resolve(2);
这两个代码示例没有区别，它们的行为完全相同。唯一的区别是，如果您在解析/拒绝之前必须执行其他逻辑，例如清除变量，则第一种方法将更具可读性。除此之外，它只是可读性。如果您只需要在条件中执行 1 行，则可以删除条件周围的 {}
来自 MDN，
我们称之为 solve(...) 当我们异步执行的操作是 成功，并在失败时拒绝(...)。
所以是的，代码示例将始终返回相同的内容，尽管正如另一个人提到的，它不是一个很好的代码片段。