io_uring是Linux 5.1+下唯一实测突破单线程2GB/s文件读吞吐的路径，但必须正确配置IOPOLL/SQPOLL、使用page对齐且512B整倍长度的O_DIRECT缓冲区，提交前重置sqe字段，completion时严格检查cqe->res并管控buffer生命周期。
直接上 io_uring 而不是 aio_read 或阻塞 write，是 Linux 5.1+ 下唯一能实测突破单线程 2GB/s 文件读吞吐的路径；但错配参数、误用内存或忽略返回值，会让性能比 epoll + 阻塞 read 还差。
io_uring 初始化必须带 IOPOLL 或 SQPOLL 标志
默认初始化（io_uring_queue_init(256, &ring, 0)）只是个“异步包装器”，底层仍走普通 syscall 路径，毫无优势。真实吞吐提升依赖内核轮询能力：
- 面向 NVMe/SSD 等低延迟存储：必须传
IORING_SETUP_IOPOLL，让内核在 submission 时直接 polling 设备完成，绕过中断开销 - CPU 密集型场景（如高并发小读+解析）：启用
IORING_SETUP_SQPOLL，内核独占一个 CPU 核跑 submission 线程，避免用户线程反复陷入 syscall - 两者不能同时设；若漏掉，
strace会看到大量io_uring_enter调用，且cqe->res延迟抖动剧烈
buffer 必须 page-aligned 且长度 512B 对齐（O_DIRECT 场景）
用 O_DIRECT 是发挥 io_uring 吞吐的关键，但它对内存和长度校验极严——错一位就返回 -EINVAL：
- 分配：必须用
posix_memalign(4096, size)，不能用new char[n]或std::vector；malloc仅保证 8/16 字节对齐，不够 - 长度：读写单位（
len）必须是 512 的整数倍；若读 131072 字节（128KB），没问题；若读 131073，内核直接拒收 - 提交前检查：
assert(((uintptr_t)buf & 4095) == 0 && (len & 511) == 0)应作为 debug 断言固化
提交前必须重置 sqe->user_data 和 flags
复用同一个 io_uring_sqe* 结构体提交多个请求是常见操作，但 liburing 不自动清空字段，极易导致 completion 错乱：
立即学习“C++免费学习笔记（深入）”；
- 每次调用
io_uring_prep_read()后，必须显式设置：sqe->user_data = (uint64_t)ctx_ptr;（上下文指针或 ID） - 必须重置
sqe->flags = IOSQE_ASYNC;（若需后台提交）或清零；残留的IOSQE_FIXED_FILE会导致后续非注册 fd 提交失败 - 不重置
user_data的典型现象：cqe->user_data总是上一次的值，回调拿到野指针，segfault或静默数据错乱
completion 处理必须检查 cqe->res，不能当字节数直接用
cqe->res 是 syscall 风格返回值，不是布尔成功标志——忽略它等于放弃错误控制：
-
cqe->res >= 0：实际读/写字节数，可安全使用 -
cqe->res == -EAGAIN：资源暂不可用，应将 buffer 挂入 pending 队列，等下次 submit 成功后再推，**绝不能立刻重试**（否则压满 SQ，返回-EBUSY） -
cqe->res == -EFAULT：buffer 未注册或地址非法，说明posix_memalign分配后没传给io_uring_register_buffers()（若用了 IOPOLL） - 常见错误：把
cqe->res直接 memcpy 到结构体字段，结果负值被截断成极大正数，后续越界访问
最易被忽略的是 buffer 生命周期与 user_data 的绑定：协程挂起后栈变量失效、堆对象提前 delete、user_data 当指针解引用却没做生命周期延长——这些不会立刻 crash，而是在高负载下间歇性丢数据或读到脏内存。
