这个问题真的戳中了Promise设计里一个很容易让人困惑的点——明明执行器函数是同步执行的，可里面抛出的异常就是绕不开Promise的“管辖范围”，外部的try...catch根本碰不到。下面我从底层规范和引擎处理逻辑来拆解这个现象：

核心原因：Promise会自动捕获执行器内的同步异常 #

ECMAScript的Promise规范里明确规定：当你调用new Promise(executor)时，JS引擎会自动给executor函数套一层隐式的try...catch。具体流程是这样的：

1. 先创建一个处于pending状态的Promise实例；
2. 同步执行executor函数，但这个执行过程被包裹在Promise内部的try块中；
3. 如果executor里同步抛出了异常，Promise内部的catch会立刻捕获到它，然后自动调用该Promise实例的reject方法，把异常作为reject的原因；
4. 这时候外部的try...catch早已经执行完毕了——因为executor是同步执行，但它的异常被Promise内部拦截处理，根本不会冒泡到外部的作用域。

结合你的代码示例分析 #

看你给出的这段代码：

try {
  new Promise(function(resolve, reject) {
    throw "Error"
  })
} catch (e) {
  console.error(`try...catch ${e}`);
}

外部的try块其实只负责捕获new Promise()这个表达式本身可能抛出的错误（比如你传入的executor不是一个函数），但executor内部的代码是在Promise自己的隐式try/catch里运行的。当你抛出"Error"时，这个异常被Promise内部捕获，直接把Promise实例的状态改成了rejected，而没有让它向外冒泡到外部的try块。

这种设计的初衷 #

Promise的核心设计目标之一是统一同步和异步操作的错误处理方式。如果允许外部try...catch捕获executor的异常，那同步错误和异步错误（比如setTimeout里抛的错）就需要用两种不同的方式处理，反而增加了复杂度。通过让Promise自动捕获内部同步异常并转化为reject状态，就能让所有Promise相关的错误都可以通过.catch()方法统一处理，保证了错误处理的一致性。

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