高性能

先说结论 多数业务服务里，epoll 依然是稳妥选择。io_uring 在某些高并发 IO 场景能更快，但复杂度也更高。 epoll 的优势 生态成熟，排障资料多 编程模型稳定 与现有网络库兼容性好 对于大部分 API 服务，epoll 足够用。 io_uring 的价值点 减少系统调用次数 提升批量提交与完成处理效率 在特定负载下降低延迟 但它要求你理解提交队列、完成队列、内核版本差异等细节。 选型建议 先压测当前 epoll 方案，定位真实瓶颈 若瓶颈明确在 IO 提交/完成路径，再评估 io_uring 预留回退方案，避免一次性全量切换 团队视角 技术选型不只看 benchmark，还要看： 团队掌握程度 线上问题可定位性 长期维护成本 小结 新能力值得关注，但架构决策应以稳定收益为中心。对大多数团队来说，逐步引入比激进替换更现实。

为什么协程不是魔法 C++20 协程让异步代码写起来像同步，但它只解决语法组织，不自动提供高性能调度。 真正决定上限的是： 任务队列策略 IO 事件分发 唤醒与线程绑定方式 一个简化示意 task<int> fetch_and_parse(socket& s) { auto buf = co_await async_read(s); co_return parse(buf); } 这段很优雅，但背后必须有 executor 驱动 co_await 的挂起与恢复。 调度层常见坑 所有任务丢进一个全局队列，热点锁竞争严重 IO 线程和计算线程混跑，尾延迟放大 协程对象生命周期管理混乱 实践建议 IO 与 CPU 密集任务分池 减少跨线程恢复，尽量本地唤醒 在高频路径避免动态分配 结语 协程把异步写法变自然，但高性能系统仍然遵循老规律：调度、内存、锁竞争。语法升级不能替代架构设计。