io_uring不能直接当“异步文件库”用，因其仅为内核提交/完成队列接口，不封装文件语义，需手动管理fd、对齐buffer、处理错误及上下文生命周期等。
io_uring 为什么不能直接当“异步文件库”用
因为 io_uring 本身只是内核提供的一组提交/完成队列接口，不封装文件语义。你调用 io_uring_prep_readv 前得自己 open() 文件、管理 fd、处理 O_DIRECT 对齐、应对 -EAGAIN 或 -EBUSY 返回——这些都不是“开箱即用”的异步 I/O，而是裸调度原语。
常见错误现象：io_uring_submit 返回成功，但读写没发生；或 read 完成后 buffer 里全是零；或高并发下大量 -EAGAIN 却没重试逻辑。
- 必须显式设置
IORING_SETUP_IOPOLL（仅限支持轮询的设备）或IORING_SETUP_SQPOLL（需 root），否则仍是 syscall 回退路径，性能无优势 -
O_DIRECT是常态，意味着 buffer 地址和长度都必须页对齐（posix_memalign分配），否则io_uring直接拒绝提交 - 同一个 ring 不宜混用阻塞/非阻塞 fd：比如用
open("/proc/sys/...", O_RDONLY)这种非存储 fd 提交到带IOPOLL的 ring，会静默失败
如何安全地复用 sqe 和管理 completion
手写库最容易崩在 sqe 生命周期错乱：提前覆盖未提交的 sqe，或 completion 回调里访问已释放的上下文。liburing 的 io_uring_get_sqe 只是取空位指针，不保活，也不自动关联用户数据。
使用场景：长连接服务中每个请求对应一次磁盘 read，需把 request 对象地址嵌入 sqe 的 user_data 字段，completion 时还原。
立即学习“C++免费学习笔记（深入）”；
- 永远检查
io_uring_get_sqe返回值是否为nullptr，满队列时它不阻塞，要主动io_uring_submit后再取 -
user_data是唯一可靠的上下文传递通道，别依赖 sqe 内存地址——ring 内部可能移动或复用缓冲区 - completion 处理必须区分
res < 0（错误）和res == 0（EOF），尤其对普通文件；res > 0才是真实字节数
Linux 5.19+ 的 IORING_OP_OPENAT2 能省多少事？
以前 open 文件必须走额外 syscall，破坏异步流水线；现在可把 open + read 合并在一个 submission 中，但代价是语义更重、容错更差。
参数差异明显：openat2 需构造 struct open_how，且 how.flags 里若设 O_PATH 或 O_NOFOLLOW，后续 read 会直接失败——不是报错，而是 res == -1 且 cqe->flags & IORING_CQE_F_MORE 为 false，容易误判为成功。
- 仅当确定文件存在且权限固定时才用
IORING_OP_OPENAT2；动态路径或权限不确定场景，老老实实先io_uring_prep_openat再链式 submit -
IORING_OP_OPENAT2不支持O_DIRECT，所以后续 read 仍需对齐 buffer，不能省掉posix_memalign - glibc 尚未封装
openat2，需自己定义struct open_how并确保字段顺序与内核一致（__kernel_timespec等细节易踩坑）
为什么 mmap + io_uring 通常比纯 io_uring 更慢
有人想用 mmap 预映射大文件，再靠 io_uring_prep_read 触发 page fault 异步加载——理论上零拷贝，实际几乎总是更慢。根本原因是 page fault 路径绕过了 io_uring 的 fast path，最终退化成普通 read() syscall。
性能影响具体体现在：相同负载下 CPU 使用率高 20%+，延迟 P99 上浮 3–5 倍，且 vmstat 显示 pgmajfault 暴涨。
- 真正零拷贝场景只适用于
IORING_OP_PROVIDE_BUFFERS+ 用户态 buffer pool，而非 mmap - 若必须 mmap，至少用
MADV_DONTNEED主动释放冷页，避免 swap 压力干扰 io_uring 提交延迟 - 不要在同一个文件上混用
mmap和io_uringread：内核 page cache 锁竞争会导致 completion 阻塞在page_cache_get_page
最麻烦的其实是信号处理——io_uring 提交过程可能被 SIGUSR1 中断，此时 io_uring_submit 返回 -EINTR，但 sqe 已部分入队，重试前必须用 io_uring_sq_ready 检查真实状态，否则重复提交会触发内核 panic 日志。
