北京
几乎每一道高级Node.js面试题，表面上问的是流、定时器、集群、内存或异步错误处理，但剥开外壳，核心永远只有一个：你是否理解，你的JavaScript代码运行在单一线程上，以及当你阻塞它时会发生什么。
面试官用这些看似分散的技术点作为入口，最终都会把你引向同一个目的地——事件循环（Event Loop）。这不是巧合，而是考察候选人对Node.js并发模型本质理解的最高效方式。
事件循环的正确打开方式
几乎所有候选人都会说“Node.js是非阻塞、异步的”。这句话本身没错，但它什么都证明不了。真正有价值的回答，是对分工逻辑的清晰阐述。
你的JavaScript代码运行在一个线程上。输入输出（I/O）操作则不是——它们被交给操作系统或线程池处理，当操作完成时，回调函数被排队送回那个唯一的线程。这就是为什么成千上万个空闲连接几乎不消耗资源，也是为什么一个昂贵的同步函数会阻塞该进程上的所有其他请求，而不仅仅是它自己所属的那个请求。
CPU密集型任务：初级与高级答案的分水岭
当被问及“如果请求处理器执行了CPU密集型操作会怎样”时，初级和高级答案的差距立刻显现。
初级答案通常是：它会变慢，可能阻塞其他请求，所以应该避免在Node中做重计算，把它移到后台任务或另一个服务中。
高级答案则直指本质：它会在整个执行期间阻塞整个进程，因为只有一个线程在运行JavaScript，所以所有其他进行中的请求都在它后面等待，即使它们本身什么都没做。更关键的是，这个问题在本地测试中永远不会暴露——因为你是唯一的用户。
一位资深工程师分享过真实案例：一次对大型负载的同步解析，给每一个并发请求都增加了数百毫秒的延迟。解决方案是：如果确实是CPU密集型工作，使用Worker Threads（工作线程）；如果问题是数据量太大，则改用流式处理。
能准确说出这个并发效应的名字，并指出它在本地环境中的隐蔽性，才是面试官想听到的“运维视角”答案。
执行顺序问题：微任务与宏任务
面试中至少会有一道关于“谁先执行”的问题。这并非琐碎的知识点，而是考察你是否清楚微任务（Microtasks）和宏任务（Macrotasks）是两个不同的队列。
一个已经resolve的Promise回调，会先于一个已经到期的定时器执行，因为微任务队列在每个阶段之间会被完全清空。这个机制在实际中最重要的后果是：一个递归的Promise回调链可以完全饿死事件循环，进程看起来还活着，但实际上什么服务都没在提供。
这个后果，比单纯的顺序记忆更有价值，也是面试官真正想听到的答案。
流与背压：生产环境才能学到的教训
流（Streams）和背压（Backpressure）是Node面试中最可靠的“高级筛选器”，因为这是只有在生产环境中把内存耗尽过才能学到的经验。
把一个大文件读入内存再发送出去，在文件不大或用户不多时没问题。流式处理则按块（Chunk）进行。但面试官真正关心的问题是：当消费者（Consumer）比生产者（Producer）慢时会发生什么？
答案是没有背压机制的话，数据块会在内存中不断排队，直到进程崩溃。
以下代码展示了没有背压的情况——无论响应对象（res）能否跟上，'data'事件都会持续触发：
// 没有背压：无论res能否跟上，'data'都会持续触发source.on("data", (chunk) => { // 处理chunk});理解背压，意味着你不仅知道流是什么，还知道如何防止系统在真实负载下崩溃。这种认知，只能来自实际运维的教训，而非文档阅读。
面试的本质：你在操作一台机器，还是在写脚本？
把所有这些面试题串联起来，你会发现一个清晰的信号：面试官在寻找的，不是会写Node.js代码的人，而是理解Node.js运行机制的操作者。他们想知道，当生产环境出现问题时，你是否能准确判断瓶颈在哪里——是CPU密集型任务阻塞了事件循环，是微任务队列饿死了主线程，还是背压缺失导致内存溢出。
这些问题的答案，都无法从语法手册中获得。它们来自对事件循环模型的深刻理解，来自在生产环境中踩过的坑，来自对“单线程”这三个字背后全部含义的清醒认知。
下一次面试时，当被问到流或定时器，不妨想想：面试官真正问的，其实是“你知道那条唯一的线程现在在干什么吗？”
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
