co_await是协程挂起点，用于交出执行权并保存局部变量状态，待异步操作完成后再恢复；它要求函数为协程、编译器启用C++20协程支持、返回类型满足promise_type约束，且awaiter正确实现三函数。
co_await 是什么，它不等于“让程序睡一会儿”
co_await 不是 sleep 或 delay，它是一个挂起点（suspend point），作用是把当前协程的执行权交还给调度器，同时保持栈上局部变量的状态，等某个异步操作（比如网络读、文件 IO）完成后再恢复执行。它只在 std::coroutine_handle 可调度、且 awaiter 实现了 await_ready/await_suspend/await_resume 三函数的前提下才真正生效。
常见错误现象：co_await 在非协程函数里用直接编译失败；在没启用 C++20 协程支持的编译器下（如 GCC 10 默认关掉）报 ‘co_await’ declared here, but no ‘await_transform’ in scope；或者挂起后永远不恢复——大概率是 awaiter 的 await_suspend 没正确触发回调。
- 必须用
-std=c++20且开启协程支持：GCC 需加-fcoroutines，Clang 加-stdlib=libc++ -fcoroutines-ts（注意 TS 已过时，优先用 C++20 标准） - 返回类型必须满足
promise_type要求，例如task<int>这类自定义协程类型，不能直接co_await一个int - 底层 IO 必须是非阻塞的，否则挂起没意义——
co_await不会帮你把read()变成异步，得靠 epoll/kqueue/IOCP 封装的 awaitable 对象
怎么写一个能 co_await 的 socket read 操作
标准库没提供现成的 awaitable socket，你得自己包装或用第三方（如 libunifex、cppcoro）。核心是让 await_suspend 把协程 handle 注册进事件循环，等 fd 可读时再 resume。
典型使用场景：一个 HTTP server 中，每个请求处理协程需要等待 client 发来完整 header，中间不能阻塞线程。
立即学习“C++免费学习笔记（深入）”；
-
await_suspend里调用epoll_ctl(EPOLL_CTL_ADD)+ 存储coroutine_handle到 per-fd 上下文，而不是直接调用handle.resume() -
await_resume应返回实际读到的字节数或错误码，不是 void —— 否则你不知道 read 成功没 - 别在
await_ready里做真实 IO：它只应快速判断是否“已经就绪”，比如缓冲区有残余数据可立刻返回，否则必须返回false触发挂起
struct async_read_op {
int fd;
std::span<std::byte> buf;
bool await_ready() { return false; }
void await_suspend(std::coroutine_handle<> h) {
register_for_read(fd, [h](ssize_t n) { h.resume(); });
}
ssize_t await_resume() { return last_read_result; }
};
// 然后就能：auto n = co_await async_read_op{fd, buf};
为什么 co_await 之后局部变量还在，但 this 可能失效
协程挂起时，栈帧被分配到堆上（通过 promise_type::get_return_object_on_allocation），所以普通局部变量（int x = 42;）能保留；但如果你在成员函数里用 co_await，而对象本身是栈上临时量或已被析构，那 resume 后访问 this->member 就是野指针。
常见错误现象：协程第一次运行正常，resume 后访问成员变量崩溃，gdb 显示 this == 0xdeadbeef；或者 valgrind 报 use-after-free。
- 确保协程生命周期 ≤ 所依赖对象的生命周期。比如不要在 lambda 捕获局部对象后，把它传给后台调度器长期持有
- 若需延长对象生命，考虑用
std::shared_ptr<T>包裹，把shared_from_this()捕获进 awaiter - 避免在析构函数里 cancel 协程：C++20 不保证协程能安全被 cancel，更稳妥的是用标志位 + 主动检查 + 提前返回
Windows 下 IOCP 和 Linux 下 epoll 的 awaiter 写法差异在哪
差异不在 co_await 语法，而在 awaiter 如何对接底层异步机制：IOCP 是“完成端口”，事件由系统主动投递；epoll 是“等待端口”，需你自己轮询或用 epoll_wait 配合线程池分发。
性能影响明显：IOCP 在 Windows 上单线程可高效处理数万连接；epoll 在 Linux 上依赖 epoll_wait 唤醒策略，若没用 EPOLLET + 边沿触发，可能重复通知导致 busy-loop。
- IOCP awaiter 的
await_suspend通常只调用ReadFileEx，不注册回调函数——完成包由系统自动入队，你的 dispatcher 线程从GetQueuedCompletionStatus拿到 handle 后 resume - epoll awaiter 得自己管理事件循环线程，
await_suspend要把 fd 加入 epoll 实例，并把coroutine_handle存到用户数据区；resume 触发必须来自 epoll_wait 返回后的显式调用 - 跨平台封装时，别试图统一接口语义：IOCP 的“完成即触发”和 epoll 的“就绪即通知”行为不同，强行抽象容易漏事件或重复 resume
最常被忽略的一点：co_await 的 suspend/resume 不是原子操作，awaiter 的 await_suspend 返回前，协程可能已被外部线程 resume——所以所有共享状态（比如存储 handle 的指针）必须用原子操作或互斥保护，哪怕看起来只写一次。
