io_uring协程需手写awaiter：实现await_ready/await_suspend/await_resume，在await_suspend中提交sqe并存coroutine_handle到user_data，cqe回调时用user_data恢复协程，buffer须堆分配或静态存储以避免栈溢出。
io_uring 需要自己管理 awaiter，不能直接用 std::coroutine_handle
标准 C++20 协程不感知 io_uring 的异步模型，io_uring 提交 SQE、等待 CQE 完全由用户控制。你不能把 co_await 直接扔给一个裸的 io_uring_sqe* —— 编译器不知道怎么挂起、怎么唤醒。
必须手写一个符合 awaiter 概念的类型：它得有 await_ready()、await_suspend()、await_resume()，且在 await_suspend() 里把 SQE 提交到 ring，并把当前协程 handle 存进 SQE 的 user_data 字段（或配套的 per-op 上下文）。
-
await_ready()应该返回false（除非极少数已知可立即完成的场景，比如缓存命中） -
await_suspend()必须调用io_uring_submit()或至少确保提交发生；否则协程永远不恢复 - 别在
await_suspend()里做阻塞操作（如io_uring_wait_cqe()），这会卡住整个线程 - 每个 awaiter 实例最好绑定唯一
io_uring_sqe*，避免多个协程共用同一 SQE 导致user_data被覆盖
如何让 io_uring 完成回调安全地 resume 协程
ring 完成后，CQE 到达，你需要从 cqe->user_data 取出之前存的 std::coroutine_handle 并调用 .resume()。但这里有两个关键约束：
- 必须保证
coroutine_handle仍有效 —— 协程不能已在别处被销毁（比如被 co_return 或异常 unwind）；常见做法是用std::shared_ptr包裹 handle，或在 awaiter 析构时检查并取消 pending SQE - 回调执行上下文未必是你的工作线程 ——
io_uring的 completion 通常由内核通过io_uring_enter(…, IORING_ENTER_GETEVENTS)或轮询/中断触发，而你大概率是在一个专用 polling 线程里调用io_uring_cqe_seen()和resume()；不能假设回调发生在任意线程 - 别在信号处理函数或硬中断上下文 resume 协程 ——
std::coroutine_handle::resume()不是 async-signal-safe
典型模式是：polling 线程循环调用 io_uring_peek_cqe() → 检查 user_data → static_cast<awaiter>(cqe->user_data)->resume()</awaiter> → io_uring_cqe_seen()。
为什么不能直接用 liburing 的 io_uring_prep_readv() 就完事
liburing 的 prep 函数只填充 SQE 字段，不提交也不关联协程逻辑。直接调用 io_uring_prep_readv(sqe, …) 后如果不手动提交、不设置 user_data、不提供 resume 路径，协程就卡死在 await_suspend()，永远不会回来。
- 漏掉
sqe->user_data = reinterpret_cast<uint64_t>(handle.address());</uint64_t>是最常见错误，导致 CQE 到来时无法定位协程 - 用
IORING_SETUP_IOPOLL时，需确保文件以O_DIRECT打开，否则 prep 成功但实际走回 blocking path，破坏协程语义 -
IORING_SETUP_SQPOLL要求 root 权限且内核线程可能调度延迟，开发阶段建议先禁用，避免调试时行为不一致 - 不同内核版本对
IORING_OP_ASYNC_CANCEL支持度不同，别依赖它来清理 pending 协程 —— 自己在 awaiter 析构中调用io_uring_cancel_files()或类似逻辑更可控
协程栈和 io_uring 内存布局冲突的实际表现
协程默认栈在堆上分配（由 promise 的 operator new 控制），而 io_uring 的 readv/writev 要求 iovec 指向的 buffer 在整个 IO 生命周期内有效。如果 buffer 是协程栈上的局部变量（比如 char buf[4096]），协程挂起后栈可能被复用，导致读写脏内存甚至段错误。
- 所有传给
io_uring的 buffer 必须是 static、全局、堆分配，或明确生命周期长于协程挂起期的对象成员 - 别在
co_await表达式里临时构造 buffer（如co_await read(fd, std::array<char>{});</char>）—— 数组生命周期只到表达式结束 - 使用
io_uring_register_buffers()可提升性能，但注册的 buffer 必须 page-aligned 且长期有效；协程频繁创建/销毁 buffer 会导致注册表膨胀或反复注册开销 - 调试时看到
Invalid argument错误码 +io_uring_submit()返回 -22，大概率是 buffer 地址非法或未注册（当启用 buffer registration 时）
真正压榨性能的关键不在语法糖，而在让每次 SQE 提交都对应一次确定的、无拷贝的、内存安全的内核交互 —— 这要求你对协程生命周期、ring 内存模型、以及两者交界处的 ownership 彻底清晰。稍一模糊，就是静默数据损坏或随机 hang 住。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
