c++的co_await和co_yield在协程中分别扮演什么角色？ (异步编程)

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 或定时器：

task fetch_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 循环），然后挂起，等待下一次迭代时被唤醒。

关键点：

• 不能在返回类型为 task 或 void 的协程里用

  

  co_yield，否则编译失败
• co_yield 不负责调度，也不等外部事件；它只是“产出 + 挂起”，恢复时机由调用方控制（如 ++it）
• 如果 yield_value 返回 void，协程挂起后无法被唤醒，容易卡死

示例：

generator fib(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 缺少对应成员，编译就断在那儿，没有运行时妥协余地。