Appearance
网络层 I/O 调研
这页收敛 Windows IOCP、Linux io_uring 与 KBEngine 现有网络层之间的研究结论，重点是工程决策，不是协议教学。
核心结论
架构语义不兼容
- KBEngine 当前网络层以 Reactor 风格为主。
- IOCP 和 io_uring 更接近 Proactor 或异步完成模型。
- 因此“给现有 poller 再加一个 IOCP 实现”并不是低成本扩展，而是可能触发接口语义重设计。
成熟库的取舍并不激进
对比成熟网络库后，可以看到常见路线并不是盲目追新：
- 有的统一用 Reactor，避免双模型复杂度。
- 有的统一抽象成异步 API，由不同平台后端适配。
- 有的坚持 Proactor 抽象，但在 Linux 上仍借助更成熟的现有机制实现。
这说明问题不在于“有没有新后端”，而在于现有接口是否值得整体重塑。
io_uring 仍不是低风险立即解
- 理论上 io_uring 很强，尤其在批量操作和零拷贝方面。
- 但在跨平台工程实践里，生态成熟度、稳定性、内核版本要求都还会显著影响落地成本。
- 调研结论更偏向“继续观察”，而不是立即重构到 io_uring 中心架构。
建议路线
短期
- 先做务实改进，优先解决当前平台上的实际瓶颈。
- 如果要补 Windows 能力，优先考虑兼容现有接口的渐进式方案，而不是一步切到全异步模型。
中期
- 持续跟踪 io_uring 在主流库和运行时中的成熟度。
- 结合 KBEngine 实际热点，再判断是否值得引入更大规模的网络层调整。
长期
- 只有在新模型已经明显优于维护现有 Reactor 路线时，才考虑整体重构。
文档边界
这类研究材料更适合放在工程指南，而不是 study/** 或 architecture/** 主正文里，原因是：
- 它主要服务于后续工程决策。
- 它讨论的是“值不值得改”和“改动代价是什么”。
- 它不直接承担 KBEngine 当前源码架构的事实说明。