最近刷技术社区的朋友应该有感觉：io_uring 的出镜率突然高得反常。
光这一个来月就相当热闹：io_uring 作者 Jens Axboe 的演讲《io_uring 的设计与演进》被搬上 B 站，配好了中文字幕。哔哩哔哩Linux 基金会峰会上，微软安全专家 Paul Moore 专门用一整场演讲复盘 io_uring 的安全踩坑史。哔哩哔哩PostgreSQL 19 确认引入 io_uring 做内核异步读取。微博Linux 内核 RDS 零拷贝与 io_uring 组合的本地提权漏洞"PinTheft"被披露，POC 已经公开。
更现实的信号在招聘端：已经有 UP 主在拆解"京东 C++ 实习一面：为什么 io_uring 比 reactor 快"这种真题了。哔哩哔哩
这技术其实 2019 年就随 Linux 5.1 进内核了，为什么 2026 年突然扎堆爆发？以及更要紧的问题——现在上车晚不晚？学不学？生产敢不敢用？
我先把结论摆出来：值得学，谨慎迁，Go 程序员可以先看热闹。 下面是账。
一、先搞懂它凭什么快：不是玄学，是两次系统调用
传统 epoll 路线处理一次网络 IO，流程是：先 `epoll_wait` 等就绪事件，等 socket 可读了，再调一次 `read` 把数据从内核拷到用户态。一次 IO，两次系统调用、两次用户态/内核态上下文切换。并发量上来以后，这点切换开销会被持续放大。知乎
io_uring 的思路简单粗暴：用户态和内核共享两块 mmap 出来的环形队列——提交队列（SQ）和完成队列（CQ）。知乎你把要做的 IO 操作（SQE）批量写进 SQ，一次 `io_uring_enter` 提交几百个请求，内核干完活把结果（CQE）写进 CQ，你直接读共享内存拿结果。开了 SQPOLL 模式，连提交那次系统调用都能省掉。
更关键的是模型变了。epoll 是"就绪通知"：内核只告诉你"可以读了"，搬数据的活还是你的线程自己干，严格定义上这叫同步非阻塞，NGINX、Redis、libevent、asyncio 全是这个模式。io_uring 是"完成通知"：内核把活干完才告诉你，这是真异步。这套玩法 Windows 的 IOCP 早在 1994 年就有了，Linux 等于迟到了 25 年才补课——这也是为什么 io_uring 出来后，Windows 自己反倒回头搞了个几乎一模一样的环形接口。知乎
在这个底座上，io_uring 还在不断加料：注册缓冲区、固定文件减少每次注册的开销，SEND_ZC / ZCRX 做零拷贝发送和接收，multishot 让一次提交持续收割多个 accept/recv 事件。这些高级能力大多在 5.19 到 6.x 这一代陆续落地，ZCRX 这种新东西更是需要很新的内核。
一句话总结：epoll 时代的天花板，是 io_uring 的起跑线。
二、别急着冲，先算三笔账
账要一笔一笔算，这正是"值不值"的核心。
第一笔：安全账。 io_uring 的快，一部分来自"绕开常规路径"，而安全体系恰恰挂在常规路径上。微软专家 Paul Moore 在 Linux 基金会演讲里复盘过：从 v5.1 到 v5.16 的几年里，io_uring 一度绕过了 LSM 访问控制，审计可见性也被破坏，后来才逐步补上凭据控制、命令透传控制这些围栏。哔哩哔哩到了今年 5 月，又出了 PinTheft 这种组合提权漏洞。知乎反过来，攻击者也盯上了它——因为 io_uring 绕过传统 syscall 审计路径，已经有人拿它做 EDR 规避。知乎所以如果你的环境安全审计卡得严，动手前先确认下安全团队的态度，别代码写完了被一票否决。
第二笔：版本账。 io_uring 的高级特性是按内核版本解锁的。知乎上讨论 Netty 原生 io_uring transport 时，有人直接给出前提：要跑最新特性得上 Ubuntu 24 这种 6.x 内核的发行版，22.04 还缺东西。知乎也就是说，如果你的生产集群还跑着 4.19、5.4 这种 LTS 老内核，"迁 io_uring"的真实成本不是改代码，是先升内核——这个决策的重量完全不一样。
第三笔：生态账，看你用什么语言。 C 语言有官方的 liburing 打底；C++ 这边 Boost.Asio 从 1.78 起提供了原生 io_uring 后端。知乎国内还有人开着基于 io_uring + C++20 协程的网络库连载。知乎Rust 有 tokio-uring、monoio、compio；Java 这边 Netty 有 io_uring transport，还在孵化期，但社区维护相当活跃，有人专职在修它的 UDP 实现。而 Go——重点来了——Go 运行时的网络层目前还是 epoll 那套 netpoller，io_uring 跟普通 Go 业务代码基本没关系。所以 Go 程序员不用焦虑，这个热闹你围观就行。
顺带一提：C++ 标准网络库至今难产（Asio 派和 Sender/Receiver 派在委员会里吵了几年），这从侧面说明——越往上的抽象越慢，而 io_uring 这种底层设施反而已经先跑起来了。知乎
三、对号入座：谁该学，谁该迁，谁该等
学生党、求职党：值得投入，现在正好。 面试题已经开始考了，而且 io_uring 本身就是 Linux IO 演进这条主线（select→poll→epoll→io_uring）的最新一站，学它等于把 epoll 八股也重新串了一遍，不亏。路线也现成：B 站上《从 select、poll、epoll 到 io_uring》这种高收藏系统课先看一遍。哔哩哔哩再跟着 liburing 写个玩具项目——有人写了"同步、epoll、io_uring 三种方式实现 HTTP 文件服务器"的对照教程，照着敲一遍，简历上就能写出真东西。微博
C++/Rust 做基础设施、存储、数据库的：必修。 PostgreSQL 19 带头，对象存储、消息队列这类高频 IO 系统都在往 io_uring 靠。微博连 Steam Deck 都深度依赖它，Valve 顺手把生态推了一把。知乎这个方向不懂 io_uring，正在变成三年前的不懂 epoll。
Java/Go 业务后端：了解即可。 说句扎心的：你的服务瓶颈大概率不在系统调用，而在数据库和下游依赖。把原理搞懂当谈资，知道 Netty 哪天把 io_uring transport 转正，就够了。
真想在生产迁的，三个前提缺一不可： 内核版本撑得住你要用的特性、服务确实 IO 密集且对延迟敏感、安全团队点头。缺一个，就再等等。
四、值得继续盯的信号
最后给一份观察清单，这几个节点动了，结论可能要更新：
PostgreSQL 19 正式发布——io_uring 异步读经受不受得住生产检验，这是块试金石；
内核侧 ZCRX 零拷贝接收的成熟度和网卡适配情况；
Netty io_uring transport 什么时候从孵化转正——Java 生态的风向标；
C++ 标准网络库的进展——io_uring 后端是变量之一；
io_uring 相关 CVE 的频率——安全，是它大规模落地前最大的那个变量。
技术选型跟买东西一个道理：不追最新，只买对路。epoll 没有过时，NGINX 和 Redis 今天还稳稳跑在上面；但 io_uring 确实是"高频 IO + 低延迟"场景里的下一代武器。学，现在就是好时候；迁，先把账算清楚再说。
