网络编程的迷思：从Reactor到协程，我们是否在过度工程化？
网络编程似乎是后端开发者的“圣杯”课题。从早期教科书里那幅经典的 socket 流程图——socket()、bind()、listen()、accept()，再到 read() 和 write() 的阻塞调用——我们几乎是被“同步阻塞”这个词喂养大的。然而，当高并发浪潮来袭，操作系统线程作为并发原语的昂贵性让我们惶恐不安，于是 select、poll、epoll，乃至 kqueue 被搬上舞台，Reactor 模式成为中流砥柱。再后来，回调地狱让人痛不欲生，Promise、Async/await、协程横空出世。短短二十年，程序员的思维从“一个连接一个线程”漂移到“一个事件一个回调”，再到“一个协程一个逻辑”。我们真的在进步吗？还是仅仅在给过度工程化披上华丽的外衣？
先客观肯定各模型的价值。同步阻塞式编程之所以被“嫌弃”，并非因为它无法处理高并发，而是因为操作系统线程的上下文切换成本在 C10K 乃至 C10M 场景下显得十分昂贵。但注意，那个时代的“百万连接”是建立在硬件资源极其有限的假设上，如今一台普通服务器动则几十核、数十 GB 内存，线程池大小调到 500 甚至 1000 时，阻塞 I/O 的吞吐真的不堪吗？许多业务数据库连接池、Redis 客户端、内部 RPC 长连接，依然大量使用同步阻塞，而且代码可读性极高。Reactor 的进步则体现在将“等待”这一行为从线程中剥离，让 CPU 始终在计算或轮询就绪事件，从而用少量线程支撑海量连接。但代价是编程模型的撕裂——逻辑被切碎为一个个回调函数，状态机被隐式地散落在各个 handler 中。于是协程出现了，它试图把异步 I/O 的底层复杂封装成同步代码的形态，让程序员“重新”用线性思维编写逻辑，而操作系统或用户态调度器负责在 I/O 等待时自动让出控制权。
然而，隐藏在这演进路径下的一个核心迷思是：我们混淆了“网络并发”与“计算密集”的边界。对于大部分互联网后端服务，真正的瓶颈是数据库访问、磁盘 I/O、外部 API 调用，而非 socket 处理本身。在这些场景中，异步模型带来的提升可能微乎其微，甚至因为任务切换和回调复杂度而引入更多 bug。更警醒的是，Reactor 模型里的事件循环一旦被某个耗时操作阻断，整个服务全部卡死，这种“全局互斥”风险远比同步阻塞模型中的单线程阻塞更加危险。为了规避这个风险，我们又引入了线程池+异步化+粘合层的复杂架构，让原本简单的“读-处理-写”逻辑需要经过多个队列和上下文切换。此时，我们是否曾反思：如果直接采用同步阻塞 + 适当的线程池，效果是否反而更稳定、更可预测？
一个更深层的独立观点是：选择哪一种网络编程模型，本质上取决于你对“时间”的假设。同步阻塞假设每个 I/O 操作会在可预期的时间内返回，线程作为资源被有效地“冻结”等待；Reactor 假设 I/O 事件是稀疏散落的，CPU 必须在事件间不断轮询以保持低延迟；协程则假设 I/O 等待是频繁但短暂的，配合调度器可以零成本切换。但业务系统往往不符合任何单一假设——你的网关有时面对大量长连接，但心跳和业务消息都稀疏；你的交易服务有时面对突发批量请求，计算密集程度远超 I/O；你的流媒体服务可能更关心带宽而不是延迟。盲从“异步优于同步”的教条，或“协程是终极解”的迷信，都会让你的系统在不匹配的抽象层上付出代价。真正的架构师应当像朴素的工匠一样，先测量、再建模，最后才选择工具。
我们还要注意到，网络编程模型的发展史，本质上是操作系统的调度权迁移史。同步阻塞把调度权交给了内核线程；Reactor 把调度权收归用户态事件循环；协程则在用户态实现了轻量级任务切换。这种迁移降低了单并发任务的资源成本，但也随之带来了公平性、确定性、可观测性上的损失。一个生产环境中的网络服务，除了并发数字，还需要考虑超时管理、熔断、追踪、限流。在 Reactor 和协程中，这些横切关注点往往需要额外注入到异步上下文中，而同步阻塞模型可以用线程局部变量、异常机制和上下文的天然隔离轻松解决。这也是为什么很多 RPC 框架在内部使用异步网络层，却对外暴露“同步”接口——它们深知程序员的心智负担不是免费的，过度工程化最终会转化为人力和事故成本。
结论并非是要回到同步阻塞时代，而是呼吁一种“按需选择”的清醒。对于大多数中小型业务系统，同步 I/O + 合理线程池是性价比最高的解决方案；对于需要支撑数十万长连接且连接间几乎独立的系统，Reactor 或 epoll 模型是合理的；对于既要高并发又要自然代码结构的团队，协程确实提供了不错的折衷。但无论选择哪种，请记住：网络编程的终极目的不是炫耀技术栈，而是让业务逻辑在网络上正确、高效、可控地流转。模型本身并无优劣，只有在特定约束下相对更合适的取舍。当我们不再沉迷于“异步至上”的时代口号，能像评估一把锤子是否适合敲钉子那样评估网络框架时，我们才真正从过度工程化的迷思中解脱出来。