简化一下你的代码：

Promise.resolve()
.then(() => {
setTimeout(() => console.info(1))
})
.then(() => {
Promise.resolve()
.then(() => {
setTimeout(() => console.info(2))
})
.then(() => {
setTimeout(() => console.info(5))
})
.then(() => {
setTimeout(() => console.info(6))
});
})
.then(() => {
setTimeout(() => {
console.info(3)
Promise.resolve().then(() => console.info(4))
})
})

进一步简化：

Promise.resolve()
.then(() => {
console.info(1)
})
.then(() => {
Promise.resolve()
.then(() => {
console.info(2)
})
.then(() => {
console.info(5)
})
.then(() => {
console.info(6)
});
})
.then(() => {
console.info(3)
// console.info(4) // 1 2 3 4 5 6
// Promise.resolve().then(() => console.info(4)) // 1 2 3 5 4 6
// setTimeout(()=>console.info(4)) // 1 2 3 5 6 4
})

你这个问题可以简化成和 React 没任何关系的问题，纯粹是浏览器任务队列的问题，Promise.resolve().then 可以生成一个微任务，setTimeout 或者你问题中的 setArr 生成的时宏任务（现代浏览器没得宏任务了，分成了更多任务列表，但是为了方便解释就还是说宏任务）

你可以观察进一步简化后的版本，以及看一下最后一个 then 里面关于不同方式 4 的输出时机，尝试理解一下。

但是不得不说，理解起来可能很困难，你需要了解 js 的事件循环以及队列优先级的问题。

大概来说，微任务优先级高，宏任务优先级低，每次事件循环按照优先级拿一遍任务。

- 最顶层的 Promise.resolve().then -> console.info(1) 立刻输出 1

- 第二个 then
-- 第二个 then 里面 Promise.resolve().then -> console.info(2) 立刻输出 2
-- 第二个 then 里面 Promise.resolve() 的第一个 then 作为一个微任务已经结束，后续的第二个 then 扔到下一次微任务队列中

- 第三个 then
-- 第一句 console.info(3) 立刻输出 3
-- 第二句：
--- 情况 1：console.info(4) 那就立刻输出 4
--- 情况 2：Promise.resolve().then(() => console.info(4)) 扔一个微任务到下次事件队列，任务是 console.info(4)
--- 情况 3：setTimeout(()=>console.info(4)) 扔一个宏任务到下次事件队列，任务是 console.info(4)

- 下一次循环
-- 微任务队列有一个
.then(() => {
console.info(5)
})
.then(() => {
console.info(6)
});
--- 这里你可以看成一个新的
Promise.resolve()
.then(()=> console.info(5))
.then(() => {
console.info(6)
});
（当然这不能真的这么看，但是为了讲解方便，你就这么理解好了。。。）
--- 所以立即执行了这个微任务 console.info(5)，把 console.info(6) 继续扔到微任务队列
-- 如果上一次循环的第三个 then 里面情况 2 ，那么在上一步的 5 输出结束后 6 的前面就有一个上一次扔过来的的微任务：console.info(4)
-- 如果上一次是情况 3 ，输出 4 这个任务在宏任务队列，那么就先不管他，把当前下一个微任务输出 6 执行，再去执行宏任务队列 console.info(4)

单纯文字讲的讲不清楚，你要实际用代码多试几次，尽可能简化代码并且尝试不同的 case ，才能大概理解这个幺蛾子事件队列

顺便感谢你提供一道好玩的面试题，下次可以拿去为难其他人（

除了「 if err != null 退格退格退格 il 」
感觉 Go 我自己用起来没啥好喷的了（

我最近解决对领导疑似 PUA 我的方法是每天找 GPT-4 去骂领导，我负责输出所能想到的所有脏字儿，GPT 负责安抚我并且一起礼貌的谴责，我感觉比对象好用多了。

@flyqie #1
说不定是怕暴露自己联系方式被开盒所以希望有需要的人主动留下自己的联系方式
但是谁会这么蠢呢…这种接口扒出来以盈利为目的给别人用总有一条很可刑的法规能套头上

用你说的这种做法，二进制+浏览器+Socket ，最终会随着项目越来越复杂需要的功能越来越多开始遇到通信上的瓶颈，重构变成下一个 Electron

要不然 Electron/NW.js 等等之流为啥要费吃巴力的用各种办法把 Nodejs 和浏览器的 js 上下文粘合在一起呢…

@param #32
是的，经常 ChatGPT 已经挂逼了，但是 status 还是绿的……但是我发现大部分挂的时候，就是 API 的状态也是红的，调 API 也能用，所以 ChatGPT 挂了我一般就先用 API 顶一下，虽然 API 比较蠢（

昨晚上就开始挂了，现在养成了一出问题就去看 status.openai.com 的良好习惯（ x

@kid1412621 #3
航班号前两位是航空公司的代码，由 IATA （国际航空运输协会）分配，两位字母或字母+数字，航司申请、IATA 确认分配。
比如厦航 MF 、川航 3U 、国航 CA 之类的。好号码都被国外早先成立的航司申请了，所以国内航司的就感觉和自己名字没啥太大关系，比如 JD 不是京东航空而是首都航空，京东(货运)航空是 JG 而不是 JD （

emm ，我怎么感觉这个层面应该算的确被 AI 打败了（

就工作而言，没有
老板没法 PUA 一个 AI ，AI 只会礼貌地回应说「对不起 blablabla 」
但是人类可能会被影响到心情甚至心理健康

@julyclyde #13 不一定搜索引擎才需要爬虫，也可能是某个模型正在学习（

拿 16-8 轻断食来说，16 个小时禁食期 + 8 小时进食期：如果在 8 小时进食期内狂吃 10 个炸鸡腿 4 杯奶茶 6 个三层皇堡 2 斤小龙虾（汤汁要拌面）

那也没啥用

试过 不行

睡不好长期肯定对精神头有影响，记忆力体力啥的也有影响。

你还好是能睡着但是早醒，我是睡不着+早醒更惨，平均入睡时长三个小时，相当于十二点关灯躺床上翻来覆去三点多才睡，偶尔能早点入睡结果两三点醒了。

早几年感觉年轻扛得住，现在完全没法正常睡觉，而且明显感觉去健身的时候体能没那么好。几乎把所有安眠药吃了个遍了。这个那个西泮、右佐匹克隆、思诺思、唑吡坦啥的，要么吃了还是没睡意，要么身体很困眼皮打架但是脑子停不下来还在想七想八。感觉原来没有焦虑症，现在被「今晚到底能不能睡着」搞焦虑了，所以还要配合吃阿伐美拉汀啥的抗焦虑药，惨的一批……今天刚去挂了个专家号，医生给用大剂量阿普唑仑+右佐匹克隆让我试试，也不知道能不能有效。

所以如果楼主或者其他人，有感觉到睡眠问题，尝试自己调整不过来的话，还是去看医生，趁着早期药能有效的时候，好好调整睡眠。

既然你都说了是偶尔才用，那就偶尔卡一卡，能用能 debug 就行了，没必要追求偶尔的极致完美

ps: 上一条回复的「口」被消除格式了，实际上是「品」和「倒过来的『品』」的排列方式
当然，主屏最左端对齐和最右端对齐、摆在中间、摆在 0.618 处、摆在 3.1415926 处的时候 dock 可能有不同的运动模式，不可知不可知

这个 dock 挺迷的，我外接了俩显示器。

------------------

如果我设置的显示器排列是：
口口
口
主显示器是下面那个，那么鼠标指针放在上面俩副屏下方晃悠的时候：
- 如果 dock 在主显示器上，可以飞到任一副屏上
- 如果 dock 在某个副屏上，那么无法飞到另一个副屏上，必须先在主屏幕晃悠下，把 dock 放到主屏，再晃悠去另一个副屏

------------------

如果我设置的显示器排列是：
口口口
主显示器是最左或最右，那么 dock 可以在任意两个显示器飞来飞去

------------------

如果我设置的显示器排列是：
口
口口
主显示器是最上，那么 dock 可以在任意两个显示器飞来飞去

------------------

甚至有时候，因为副屏尺寸不一样，有几个副屏和主屏接壤（比较小的副屏是和大副屏顶端对齐，只有大副屏和主屏接壤；还是副屏底端对其，均与主屏接壤）、主副屏边境线长度等等都会影响 dock 到底能不能自由的飞来飞去。

我感觉这应该是 Apple 比较厉害的 feature 了，可能有一套复杂的物理学规律和算法来决定 dock 的行动范围和轨迹，给 Apple 点个赞！

@cnbatch #3
Windows Server 2008 内核 6.0 -> Windows Vista
Windows Server 2008 Server R2 内核 6.1 -> Windows 7
Windows Server 2012 内核 6.2 -> Windows 8
Windows Server 2012 R2 内核 6.3 -> Windows 8.1
应该是这样的对应关系