Promise.resolve、Promise.resolve().then()等三种Promise创建方式有什么差异？

你给出的示例代码中三种写法最终输出的settled结果一致，但创建流程、执行时序、错误处理逻辑存在本质区别，以下逐一拆解：

1. 第一种写法：Promise.resolve(API(...)) #

• 核心逻辑：Promise.resolve的入参是同步求值的，API会在当前同步上下文立即执行。
• 规则触发：如果Promise.resolve接收的参数本身是原生Promise实例，会直接返回该实例，不会额外包装。也就是说pro1和API('I am inside resolve')返回的Promise是同一个对象。
• 错误处理：如果API执行时同步抛出非Promise rejection的普通错误，该错误会直接同步抛到外层上下文，不会被Promise自动捕获。

2. 第二种写法：Promise.resolve().then(() => API(...)) #

• 核心逻辑：首先创建一个状态为fulfilled的空Promise，then的回调函数会被推入微任务队列，等待当前同步代码全部执行完成后才会异步调用API。
• 规则触发：then方法始终会返回一个新的Promise实例，这个新实例的状态会和回调返回的API生成的Promise绑定，两者不是同一个对象。
• 错误处理：API执行时的同步错误、返回的Promise rejection都会被then自动捕获，转化为then返回的新Promise的rejection状态，不会泄漏到外层上下文。

3. 第三种写法：new Promise((resolve) => resolve(API(...))) #

• 核心逻辑：new Promise的执行器函数是同步执行的，因此API会在当前同步上下文立即调用，和第一种写法的API执行时机一致。
• 规则触发：当resolve方法接收的参数是Promise实例时，会自动触发“解包”逻辑：外层新创建的Promise会等待入参Promise settled，状态和结果完全跟随入参Promise，但外层Promise是全新的实例，和API返回的Promise不是同一个对象。
• 错误处理：API执行时的同步错误会被new Promise的执行器自动捕获，转化为外层Promise的rejection状态，不会泄漏到外层上下文。

• 执行时序差异：仅第二种写法的API是异步（微任务阶段）调用，第一种、第三种的API都是同步调用
• 实例标识差异：第一种写法返回的是API生成的原生Promise实例，无额外包装；第二种、第三种返回的都是额外创建的包装层Promise实例，仅状态与内部API生成的Promise同步
• 错误容错差异：第一种写法无法捕获API的同步抛出错误，第二种、第三种写法都可以自动捕获API的同步错误，转化为Promise rejection

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