coroutine_handle 必须在协程 suspended 状态下安全 resume()，已结束或销毁的 handle 调用 resume() 会导致未定义行为；需检查 h.done() 再调用，避免全局长期持有，且依赖 promise 对象存活。
coroutine_handle 怎么安全获取和调用
协程对象本身不直接执行，必须通过 coroutine_handle 启动或恢复。常见错误是拿一个已销毁协程的 handle 去 resume()，触发未定义行为——程序可能当场崩溃，也可能静默出错。
关键原则：handle 只在协程处于 suspended 状态时才可安全 resume()；一旦协程执行完毕（包括被 destroy()），handle 就失效。
- 用
co_await返回的 awaitable 保证 handle 生命周期可控，别手动 new + destroy - 不要把
coroutine_handle存到全局或长期持有的容器里，除非你明确管理了协程状态 - 检查
h.done()再调用h.resume()，尤其在异步回调中——网络超时后收到响应再 resume 就很危险
示例：auto h = promise.get_return_object().handle; 这个 handle 必须在 promise 对象还活着、且协程未结束时使用。
promise_type 为什么必须实现 get_return_object / initial_suspend / unhandled_exception
编译器生成协程框架代码时，会硬性调用这几个函数。缺任何一个，clang 报 no member named 'get_return_object'，gcc 报类似 SFINAE 失败，根本过不了编译。
立即学习“C++免费学习笔记（深入）”；
它们不是可选项，而是协程语义的骨架：
-
get_return_object()：决定协程返回什么（比如Task<int></int>），返回对象里通常存着coroutine_handle -
initial_suspend()：控制协程启动时机——suspend_always{}表示创建即挂起，suspend_never{}表示立即执行到第一个co_await -
unhandled_exception()：协程内抛异常但没被捕获时的兜底逻辑，不实现就直接 terminate
注意：final_suspend() 也必须实现，否则编译失败；它决定协程结束时是否自动挂起，影响资源清理时机。
co_await 的 awaitable 对象为什么常要重载 operator co_await
不是所有类型都能直接 co_await。比如你写 co_await some_future;，编译器会先找 some_future.operator co_await()，找不到就看 await_transform，最后 fallback 到隐式转换——但多数情况你要自己提供。
典型陷阱：忘了加 const & 重载，导致右值临时对象无法 await；或者返回的 awaiter 没实现 await_ready/await_suspend/await_resume 三件套。
- awaiter 的
await_suspend返回void、bool或另一个coroutine_handle，含义完全不同：返回true表示已挂起，false表示继续同步执行 - 如果 awaiter 在栈上构造（比如局部变量），确保它生命周期覆盖整个挂起期间，否则
await_suspend里访问野指针 - 标准库的
std::experimental::suspend_always是 awaiter 示例，但 c++20 正式版已移除 experimental，得自己写
异步 I/O 场景下，为什么不能直接 co_await read() 系统调用
linux 的 read() 是阻塞系统调用，直接 co_await read(fd, buf, n) 不会让出线程，整个线程卡住——协程没意义，还损失调度开销。
真正可行的是配合非阻塞 fd + epoll/io_uring，让 awaiter 在 fd 可读时才 resume。这需要底层事件循环支持，不是语言特性自带的。
- libuv、Boost.Asio、cppcoro 都封装了这类 awaitable，比如
asio::async_read返回的 awaitable - 自己实现需注册 fd 到 epoll，
await_suspend中调用epoll_ctl(ADD)，然后把当前 handle 存进事件回调上下文 - 忽略
EAGAIN/EWOULDBLOCK错误直接返回，否则 awaiter 会误判为“已完成”，导致数据读不全
协程不等于异步 I/O，它只是让异步代码写起来像同步。底层还是得靠非阻塞 + 事件驱动，这点容易被教程带偏。