@just4id 手机热点可以解决短期的问题。一是公司楼层比较高，手机网络比较差。二长期切换感觉很麻烦，所以才想到说自己用移动 wifi，可是公司不允许

@vk42 适应两天看看情况，实在不行还是重新换工作吧

@vk42 有点可怕，律师函警告

@leon0903 是啊，太年轻了。入职这些没问清楚，他们也没提一下这个事，之前还几个 offer 里面选，这个离家比较近就选择了这个。现在可麻烦了。

@coloz 有白名单，我感觉都好一点。现在我这情况啥也访问不了，给个淘宝镜像装装包也能说的过去啊。

@yukiloh 感觉如果有员工有这个心眼了，想泄露也有一堆更简单的方法啊。

@yuang 不知道刚入职就离职，会不会有什么影响。而且今年的疫情影响，武汉有点难啊

@shansing 不是的

@ruby0906 哈喽，不是访问国外网站，是除了公司内部局域网外的，其他外部网站都访问不了。

https://cli.vuejs.org/zh/guide/css.html#%E5%90%91%E9%A2%84%E5%A4%84%E7%90%86%E5%99%A8-loader-%E4%BC%A0%E9%80%92%E9%80%89%E9%A1%B9

可以参考 vue-cli 的传递 css 预处理器全局配置

@nikolausliu dcatfly 的意思是 stat 中嵌入 read 的异步操作，所以第一轮完成的是 stat 查询文件状态，这时再去发送读取文件的异步，所以可能导致读取的回调在第二轮 polling 中执行。最终就导致了，immediate > io。但是现在 stat 的回调也是后于 immediate 执行。所以应该与 readfile 是否包含多个 io 异步没关系。

@dcatfly 哈喽，如果说 fs.readFile 可能包含多个 IO 异步，确实可以解释 immediate 出现在 io 之前输出的现象。但是我这边把 fs.readFile 替换成 fs.stat 依然是 timer > immediate > io。至此根据官方文档的说明，tcp ECONNREFUSED 的顺序属于 pending callbacks 阶段，我这边添加了一个无效的 tcp 请求，输出顺序是 timer > immediate > io > net error。不知是否是我的代码有误，可能分享一下你的具体的输出 stat > immediate 的代码。

此外官网中 polling 阶段进入时有这样的描述

When the event loop enters the poll phase _and there are no timers scheduled_, one of two things will happen:

这好像没有涉及到如果还有 timers 存在的话情况，因为下面有描述到 immediate 也是一种特殊的 timers。这因此我才有猜想第一次 polling 会检查 timers。不知道这边的逻辑具体是怎样的。

@nikolausliu 哈喽，我这边查了 nodejs 的官方英文文档。关于 eventloop 执行流程，我这边的理解如下。首先是 timer 阶段，执行 timer queue 中的函数。然后是 sys pending 阶段，就不多介绍了，主要是执行系统回调。然后是最重要的 polling 阶段，该阶段的两个主要功能就是一根据 timer 所指定的时间阈值和 io 计算 polling 时间，二执行 poling queue 中出现的 io 等回调函数。polling 的流程文档有部分逻辑描述不是很清晰，大致如下，在没有 timer 的情况下，判断队列是否为空，则阻塞等待；如果不为空，则执行其中的值。当执行完毕时，也就是队列为空时，再次判断所执行的脚本中是否有 timer，有 immediate timer 则进入 check 阶段执行，有到期的 timeout timer 则重回 timer 阶段执行。至此 polling 阶段结束。后面的 check 和 close 阶段不多介绍。

那你遇到的问题可以这样解释，程序进入主程序执行，初始化事件循环。timer 放入 timer queue，发起 file io 注册回调，for 循环阻塞进程，immediate 放入 immediate queue。主程序执行完毕，进入事件循环。timer 中执行已到期函数（这里因为执行主程序时阻塞了一段时间，所以 timer 肯定到期了。不然这里就存在 timer 到没到期，影响 immediate 与 timer 的输出顺序），输出 timer，然后 immediate 中有值，执行。然后等待 io 或执行 polling queue。最后再次去 immediate 和 timer 中判断是否有待执行函数。所以输出顺序是 timer immediate io.

这也和官方文档中的示例所吻合，在 setTimeout 中再设置一个 timer 和 immediate，timer 阶段 parent timer 执行，进入 polling 时会根据 childtimer 来计算时间，此时没有 io script 执行，所以 timer 有可能执行的很快到期了，也有可能没有到期，然后进入 check 阶段执行。所以出现了随机顺序的输出。官网中的 io polling 中有 script 设置了 immediate，所以稳定先输出 immediate，而无论 timer 是否到期了都是第二轮以后的 tick 中的 timer 执行。

所以上述两个 demo 程序的分歧点就在于，进入后 polling 最开始的逻辑是否要检测 immediate 是否存在。根据结果来说，第一次 tick 需要检测并执行，后面 tick 不需要。根据有些文章说明，底层的 libuv 确实存在三种 tick 类型的区别。这边因为小的对 C 的知识也不太熟悉，只能后续再求解了。

附上官方文档，https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/

写的有点多了，后续整理成文章。有没说清，或理解不正确的地方，还请多多指教。

@nikolausliu 哇，这边测试的时候居然放在 timeout 中也出现了，timer > immediate 的情况。看来这边的执行情况确实有问题。只能求助其他大大，我去 github issus 找找看再来。

setImmediate 在官方文档中已写明，是在当前时间循环回合结束是调用。但是实际测试会发现，首次执行存在 timer 先于 immediate 执行的情况，阮一峰大大的文章也有说明首次存在随机现象，与机器性能有关。所以你可以把你的代码包裹在一个 timeout 中执行，执行结果就会稳定先执行 setImmediate > timer，至于 io 的执行顺序按照你可以多执行几次，会出现先于 io > setImmediate > timer，也会出现 setImmediate > timer > io 情况，所以 io 的完成时间是不可预估的（这边是我自己的理解）。关于出现你的这个现象，是因为阻塞了进程，导致了 timer>immediate。