Promise执行顺序差异探究：return与return promise的区别

两个案例的核心区别仅在于then回调的返回值：caseA中回调返回默认的undefined，caseB中回调返回当前的promise变量，这直接导致了执行逻辑的天差地别。

caseA 执行流程（输出：914258367） #

1. 同步代码优先执行，先输出9。
2. 初始promise是已resolved状态，进入第一个then回调，输出1。
3. 创建promise2后，它的两个then回调（分别输出2、3）被加入微任务队列。
4. 回调内同步代码输出4，随后返回undefined——此时第一个then会生成一个立即resolved的新Promise，这个新Promise的后续then回调（即负责输出5的那个）被加入微任务队列。
5. 同步代码执行完毕，开始处理微任务队列：先执行promise2的两个回调输出2、3；接着执行第一个then返回的Promise的回调，输出5。
6. 进入输出5的回调后，重复类似逻辑：创建promise2的两个then回调（输出6、7）加入微任务队列，同步输出8，返回undefined使当前then生成的新Promise立即resolved。
7. 继续处理微任务队列，依次输出6、7，最终形成完整输出顺序。

caseB 执行流程（输出：91423，5/6/7/8无输出） #

1. 同样先执行同步代码输出9。
2. 进入第一个then回调，输出1，创建promise2的两个then回调加入微任务队列，同步输出4。
3. 关键问题在这里：回调返回的是promise变量——此时promise正是当前then方法正在生成的Promise对象，这就形成了循环引用：这个Promise需要等待自己resolved才能完成resolved，陷入了永远pending的死循环。
4. 由于第一个then返回的Promise永远不会resolved，后续绑定的then回调（负责输出5的那个）永远不会被触发。
5. 微任务队列仅处理promise2的两个回调，输出2、3后就没有后续任务了，因此5、6、7、8完全不会执行。

内容的提问来源于stack exchange，提问作者Won Jin Kim