POSIX AIO 在 Linux 上不可靠，因其依赖 glibc 线程池模拟，非内核原生异步；推荐直接使用 io_uring——Linux 5.1+ 原生异步接口，支持 buffered I/O、零拷贝、无锁，性能更优且更可控。
POSIX AIO 在 Linux 上实际不可靠，别硬上 aio_read/aio_write
Linux 内核原生不支持真正的 POSIX AIO（即内核态异步 I/O），glibc 提供的 libaio 兼容层其实是用线程池 + 阻塞 I/O 模拟的。这意味着：aio_read 调用后，底层仍可能阻塞线程、触发上下文切换，且无法利用 io_uring 或 kernel-native async path。实测在高并发小文件场景下，吞吐反而低于 epoll + 线程池 + read/write 的组合。
常见错误现象：aio_error 返回 0 但 aio_return 返回 -1 且 errno == EAGAIN；或 aio_suspend 长时间不返回，实际 I/O 却早已完成（线程池调度延迟导致）。
- 仅当使用
io_submit/io_getevents（即 libaio 的 native 接口）时，才真正绕过 glibc 封装，进入内核 AIO 子系统（但仅限 O_DIRECT 文件） - 普通文件（无
O_DIRECT）+aio_read→ 必走 glibc 线程池，和自己开 pthread 几乎没区别 - Linux 5.1+ 已标记
POSIX AIO为 legacy，文档明确建议迁移到io_uring
想用真异步？直接上 io_uring，liburing 封装足够好用
io_uring 是 Linux 5.1+ 原生异步 I/O 接口，零拷贝提交/完成队列、无锁设计、支持 read/write/fsync/splice 等全部文件操作，且无需 O_DIRECT 也能高效运行。C++ 项目接入只需链接 -luring，比 POSIX AIO 更轻量、更可控。
典型流程：调用 io_uring_queue_init 初始化 ring → io_uring_prep_read 构造请求 → io_uring_submit 提交 → io_uring_wait_cqe_nr 等待完成。
立即学习“C++免费学习笔记（深入）”；
- 避免手动管理 SQE/CQE 内存：用
io_uring_get_sqe获取空闲 SQE，别自己 malloc - 提交前务必检查
io_uring_sq_ready，防止 ring 满导致io_uring_submit返回 -EBUSY - 完成事件中，
cqe->res是实际字节数或负的 errno（如 -EINTR 不代表失败，需重试） - 不要在回调里做耗时操作：
io_uring完成回调本质是用户轮询结果，业务逻辑应尽快 dispatch 到 worker 线程
为什么 O_DIRECT + libaio 也难达标？内核页缓存绕过代价大
有人试图用 O_DIRECT + io_submit 强行启用内核 AIO，但这要求：对齐的 buffer（posix_memalign）、对齐的 offset 和 length（通常 512B 或 4K）、且完全绕过 page cache。后果是：小随机读写性能暴跌，因为失去预读、page cache 合并等优化；SSD 寿命加速消耗；部分文件系统（如 XFS）对 O_DIRECT 有额外锁竞争。
-
O_DIRECTbuffer 必须用memalign(4096, size)分配，malloc的内存大概率不对齐，io_submit直接返回 -EINVAL - 即使对齐，
ext4在O_DIRECT下仍可能 fallback 到 buffered path（如遇到 hole），行为不可控 - 现代 NVMe 设备 +
io_uring+ 默认 buffered I/O，实测随机读 QPS 反超O_DIRECT+libaio30% 以上
C++ 封装要点：别封装过度，暴露 ring 生命周期和错误码语义
写一个 C++ IoUringFile 类时，重点不是“把接口变漂亮”，而是让调用方清晰感知 ring 状态、submission 失败原因、以及 cqe->res 的 errno 解包逻辑。过度封装（比如隐藏 io_uring_submit 返回值）会导致线上问题排查困难。
- 构造函数必须接受
int entries（ring 大小），默认 256 不够用；生产环境建议 1024~4096 - 提供
submit_now()和submit_deferred()两个提交入口：前者立即io_uring_submit，后者只入队，由外部统一提交（利于批量合并） - 错误处理必须区分：ring 满（-EBUSY）、参数错（-EINVAL）、文件句柄无效（-EBADF）、内核资源不足（-EAGAIN）——每种对应不同退避策略
- 不要在析构里自动
io_uring_queue_exit：若对象被 move 或多线程共享，容易 double-free
真正棘手的是 completion event 的语义一致性：同一个 cqe 可能因 timeout、cancel、或 I/O 自身失败而抵达，cqe->res 值含义完全不同，这里没有银弹，只能靠业务层根据上下文判断。
