Promise中嵌套的setTimeout与普通setTimeout执行顺序差异疑问

• setTimeout的执行优先级和它的书写位置无关，只由定时器延时时长、同延时下的注册顺序两个因素决定
• Promise内部的setTimeout本身也是普通宏任务，不会享受微任务优先级，只有Promise的then/catch/finally回调才会进入微任务队列

1. 两个1000ms定时器输出顺序为timeout先执行的原因 #

你写的第一段测试代码中，JS主线程是同步逐行执行的：

// 第一步：同步执行，先注册第一个1000ms定时器，浏览器计时模块开始计时
setTimeout(() => {
  console.log('timeout');
}, 1000);

// 第二步：同步执行，实例化Promise，构造函数内代码立即执行，注册第二个1000ms定时器
let promise = new Promise(function(resolve, reject) {
  setTimeout(() => resolve('promise!'), 1000);
});

// 第三步：同步执行，注册then回调，等待Promise状态变更
promise.then(
  (result) => console.log(result),
  (err) => console.log(error)
);

两个定时器的注册有微小的先后差（几毫秒级），计时到期后，先注册的普通setTimeout回调先被推入宏任务队列，先执行打印timeout。随后第二个定时器回调执行触发resolve，此时才会把then回调推入微任务队列，当前宏任务执行完毕清空微任务时打印promise!，因此最终顺序是timeout -> promise。

2. 直接resolve时promise先输出的原因 #

第二段测试代码符合微任务优先级规则的原因是，定时器没有嵌套在Promise的异步逻辑里：

// 第一步：同步执行，注册0ms延时的setTimeout，回调会进入宏任务队列等待执行
setTimeout(() => {
  console.log('timeout');
}, 0);

// 第二步：同步执行，实例化Promise，直接触发resolve
let promise = new Promise(function(resolve, reject) {
  resolve('');
});

// 第三步：同步执行，注册then回调，因为Promise已经是fulfilled状态，then回调直接被推入微任务队列
promise.then(() => {
  console.log('promise');
});

主线程同步代码执行完毕后，会优先清空所有微任务，此时先打印promise，微任务清空后才会执行宏任务队列里的setTimeout回调，打印timeout。

• 不要把Promise本身和Promise内部的异步任务混淆：只有Promise的回调方法（then/catch/finally）属于微任务，写在Promise构造函数里的setTimeout、fetch等异步任务本身的类型、优先级不会发生变化。
• 相同延时的setTimeout执行顺序完全遵循「先注册先执行」的规则，和写在哪个作用域下没有关系。

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