根本原因是io_uring_submit()仅提交SQE到队列，不触发内核执行；需显式唤醒（如再次submit或启用SQPOLL/IOPOLL）或等待就绪通知，否则CQE不会生成。
io_uring_submit() 后为什么没看到 read 或 write 完成？
根本原因不是提交失败，而是你没主动触发内核处理——io_uring_submit() 只是把 SQE（submission queue entry）推入提交队列，不保证立即执行。内核通常靠两种方式推进：一是显式调用 io_uring_submit()（或带 IORING_SQ_NEED_WAKEUP 的变体），二是等待 I/O 就绪时由内核自动收割（依赖 IORING_SETUP_IOPOLL 或就绪通知机制）。常见错误是提交后直接去轮询 CQ（completion queue），但 CQE 还没生成。
实操建议：
- 确保 SQ ring 有足够空位：提交前检查
io_uring_sq_space_left(&ring)，小于预期请先收割完成事件释放空间 - 提交后必须调用
io_uring_submit()（非io_uring_submit_and_wait()除非你确定要阻塞等就绪） - 若启用了
IORING_SETUP_SQPOLL，需确认内核线程正在运行（ps aux | grep io_uring查io_uring-sq），否则提交会静默失败 - 调试时加
io_uring_cqe_seen(&ring, cqe)消费完每个 CQE，否则 CQ ring 满了会导致后续提交卡住
如何用 io_uring_prep_readv() 和 io_uring_prep_writev() 提交批量请求？
批量不是靠“一次提交多个 SQE”这个动作本身，而是靠在单次 io_uring_submit() 前，连续填满多个 SQE 并 advance SQ tail。关键在内存布局和缓冲区管理：所有 iovec 必须是用户态固定地址（不能是栈上临时变量），且推荐用 io_uring_register_buffers() 预注册，避免每次提交都做地址翻译开销。
实操建议：
- 用
io_uring_get_sqe(&ring)循环获取 SQE，每拿到一个就调用io_uring_prep_readv(sqe, fd, &iovec, 1, offset)，offset 按需递增 - 若读写同一文件的连续区域，offset 应严格递增，避免内核内部锁竞争；随机 offset 则无此问题但可能降低预读效率
- 对大量小 IO，启用
IORING_SETUP_IOPOLL可绕过中断、直接轮询设备状态，但仅适用于支持 polling 的设备（如 NVMe、某些网卡），普通 SATA 盘无效 - 注意
iovec.iov_base必须是mmap(MAP_HUGETLB)或posix_memalign(4096, size)对齐的内存，否则注册失败或性能骤降
高效批量收割 CQE：为什么 io_uring_peek_batch_cqe() 比循环 io_uring_peek_cqe() 快？
io_uring_peek_cqe() 每次都查 CQ ring 的 head/tail 并做原子比较，而 io_uring_peek_batch_cqe() 一次性读取当前可用 CQE 数量，再用指针偏移批量访问，省去重复的 ring 边界检查和原子操作。实测在高吞吐场景下，批量收割可减少 30%+ 的 CPU 时间消耗。
实操建议：
- 始终用
int count = io_uring_peek_batch_cqe(&ring, &cqe_ptr, MAX_BATCH)获取一批 CQE 指针，再遍历处理 - 处理完每个 CQE 后必须调用
io_uring_cqe_seen(&ring, cqe_ptr[i])，否则该 CQE 会被重复返回 - 若
count == 0，不要立刻 sleep，先检查是否需要提交新请求（防止饥饿），再考虑io_uring_wait_cqe_nr(&ring, &cqe, 1)阻塞等待 - 避免在收割循环里做耗时操作（如 printf、malloc），CQE 处理应只更新状态、发新请求、或唤醒等待线程
踩坑最多的三个配置组合：SQPOLL + IOPOLL + 注册 buffers
这三个特性叠加时，行为耦合度极高，稍有不慎就会静默失败或性能反降。例如：启用 IORING_SETUP_SQPOLL 但未用 io_uring_register_files() 管理 fd，会导致每次 submit 都触发内核路径查找；又或者开了 IORING_SETUP_IOPOLL 却对普通 ext4 文件做 read，IOPOLL 实际不生效但仍付出额外判断开销。
实操建议：
- SQPOLL 模式下，必须用
io_uring_register_files(&ring, fds, count)预注册所有 fd，否则每个 SQE 的 fd 字段会被忽略，系统调用回退到标准路径 - IOPOLL 仅对 direct I/O 生效（open 时带
O_DIRECT），且文件系统需支持（XFS/Btrfs 推荐，ext4 需 5.12+ 内核并挂载选项io_uring=on） - 注册 buffers 后，
iovec.iov_base必须落在注册的地址范围内，否则io_uring_prep_readv()会静默失败（返回 -1 且cqe->res == -EBADF，非常难排查） - 生产环境首次启用 SQPOLL，请用
perf record -e 'io_uring:*' -a确认内核线程是否真在工作，而不是 fallback 到普通 submit 路径
最易被忽略的是：CQE 的 cqe->user_data 字段必须在提交 SQE 前设置，且不能为 0（0 是保留值），否则批量收割时无法区分请求来源——这个值一旦设错，整个请求上下文就断了，debug 成本极高。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
