co_await用于挂起协程等待异步操作完成，触发await_ready/await_suspend/await_resume协议；co_yield用于generator中产出值并挂起，是promise.yield_value的语法糖。
co_await 用于挂起并等待异步操作完成
co_await 的核心作用是把当前协程暂停，交出控制权，等某个 awaitable 对象（比如 std::future、自定义的 awaiter）就绪后再恢复执行。它不是简单“等”，而是触发一整套挂起/恢复协议：调用 await_ready 判断是否可立即返回，否则调用 await_suspend 注册恢复逻辑，最后通过 await_resume 取回结果。
常见错误现象包括：
- 对非 awaitable 类型（如普通
int）使用co_await，编译报错no matching function for call to 'operator co_await' - 忘记在
await_suspend中正确传递coroutine_handle，导致协程永远不恢复 - 在
await_resume中抛异常但没处理，引发未捕获异常终止
典型使用场景是等待 I/O 或定时器：
taskfetch_data() { auto res = co_await http_get("https://api.example.com/data"); // 挂起，等网络响应 co_return res.status_code; }
co_yield 用于向协程生成器输出值并挂起
co_yield 只在 generator 这类协程类型中合法，它的本质是 co_await promise.yield_value(value) 的语法糖。每次执行 co_yield x，协程就把 x 交给调用方（比如 for-range 循环），然后挂起，等待下一次迭代时被唤醒。
立即学习“C++免费学习笔记（深入）”；
关键点：
- 不能在返回类型为
task或void的协程里用co_yield，否则编译失败 -
co_yield不负责调度，也不等外部事件；它只是“产出 + 挂起”，恢复时机由调用方控制（如++it） - 如果
yield_value返回void，协程挂起后无法被唤醒，容易卡死
示例：
generatorfib(int n) { int a = 0, b = 1; for (int i = 0; i < n; ++i) { co_yield a; int next = a + b; a = b; b = next; } }
co_await 和 co_yield 的底层行为差异
二者都依赖协程 promise 类型的成员函数，但触发路径不同：
-
co_await expr→ 调用expr.operator co_await()→ 最终调用 promise.await_transform/await_ready等 -
co_yield val→ 展开为co_await promise.yield_value(val)→ 所以必须确保promise.yield_value返回一个 awaitable
性能上：co_await 可能引入调度延迟（如线程切换），而 co_yield 通常只是栈保存+跳转，开销更低；但两者都避免了传统回调嵌套，提升可读性。
兼容性注意：co_yield 在 C++20 中要求编译器支持 generator（如 MSVC 19.3x+、Clang 16+），GCC 13 才开始实验性支持；co_await 支持稍早，但 awaitable 实现仍需谨慎适配 ABI。
容易混淆的边界情况
最常被忽略的是协程类型与关键字的绑定关系：
- 写
task协程却误用co_yield：编译器报错'co_yield' cannot be used in a coroutine that does not support yielding - 写
generator却只用co_await不用co_yield：协程变成单次执行，失去“迭代器”语义 - 在
co_await表达式里调用一个返回generator的函数，却不遍历它：只是构造了一个未启动的 generator 对象，不会触发任何协程逻辑
真正要记住的不是语法，而是每个关键字背后绑定的 promise 接口契约——一旦 promise 缺少对应成员，编译就断在那儿，没有运行时妥协余地。
