这一小节是第三章的开篇，朴灵作者用非常清晰的逻辑解释了：为什么Node.js必须选择异步I/O模型，而不能像传统服务器那样用阻塞I/O。
核心问题：高并发场景下的资源利用率
作者先抛出一个现实问题：
现代Web应用往往需要处理大量并发连接（成千上万甚至更多），典型场景包括：
- 静态文件服务
- 数据库查询
- 第三方API调用
- WebSocket长连接
如果采用传统的阻塞I/O（同步I/O），会发生什么？
阻塞I/O的两种常见实现方式及其缺陷
-
多进程模型（如早期的Apache prefork模式）
- 每个连接fork一个进程
- 优点：简单、隔离好
- 缺点：进程创建/销毁开销极大，内存占用高，几千并发就容易耗尽资源
-
多线程模型（如Apache worker模式、Java Tomcat、PHP-FPM）
- 每个连接一个线程
- 优点：比进程轻量
- 缺点：
- 线程栈默认1~8MB，1万个连接就可能占用几十GB内存
- 上下文切换开销大（CPU在大量线程间切换）
- 仍存在阻塞：一个慢请求（如数据库查询）会卡住整个线程
作者用一个经典比喻：
想象一家餐厅（服务器），顾客（请求）很多。如果每个顾客点菜后，服务员（线程）就站在旁边干等厨房做好菜才去服务下一个顾客，那服务员的利用率极低，大部分时间在“阻塞等待”。餐厅要服务更多顾客，就得雇更多服务员，成本爆炸。
异步I/O（非阻塞I/O）的优势
异步I/O的思路是：
- 服务员点完菜后就去服务其他顾客
- 厨房做好菜后主动通知服务员（回调或事件）
- 一个服务员就能高效服务大量顾客
在操作系统层面：
- 用户态发起I/O请求后立即返回，不等待
- 内核完成I/O后通过信号、回调等方式通知
- 应用程序只需一个线程（或少量线程）就能处理海量并发
异步I/O带来的好处
- 极高的并发能力：单线程轻松处理上万连接
- 资源占用极低：内存、CPU开销小
- 响应延迟低：快速请求不会被慢请求阻塞
Node选择的必然性
JavaScript本身是单线程语言（浏览器遗留），没有线程管理负担。
Ryan Dahl在创建Node时明确目标：构建高性能Web服务器，处理大量I/O密集型请求（而非CPU密集计算）。
因此，异步I/O + 事件驱动成为Node的必然选择。
作者最后总结一句话（很多读者都记住了）：
“Node.js生来就是为了解决I/O瓶颈而设计的。”
这一小节读完，你就明白了Node的核心哲学：让I/O不再成为瓶颈，让单线程发挥最大效能。
