C++20协程是编译器支持的底层机制，非语法糖，不绑定运行时模型；co_await等关键字触发用户定义的挂起/恢复协议，需配合库（如cppcoro、Boost.ASIO、libunifex）实现async/await语义。
C++ Coroutines 是语言级的异步构造，不是语法糖
不同于 C# 或 JavaScript 中的 async/await，C++20 的协程是编译器支持的底层机制：它不绑定任何运行时模型，也不自带调度器、任务类型或执行上下文。你写的是 co_await、co_yield、co_return，但这些关键字本身不实现异步逻辑——它们只是触发用户定义的挂起/恢复协议（通过 awaitable 类型的 await_ready/await_suspend/await_resume）。这意味着：
- 你可以用它实现 generator、stackless fiber、状态机，甚至同步阻塞语义；
- 也可以配合 std::execution（C++26 路线）或第三方库（如 libunifex、cppcoro、Boost.ASIO）构建类 async/await 的高层抽象。
所谓 “C++ 的 async/await” 实际是库封装，非标准特性
标准 C++ 没有 async 函数或 Task 类型。你在项目中看到的类似写法，比如：
Taskfetch_data() { auto res = co_await http_get("https://api.example.com"); co_return res.status_code(); }
这背后依赖的是某个协程库提供的 Task 类型及其 awaitable 接口。常见选择包括：
- cppcoro：提供 task、async_mutex、when_all 等，轻量易读，适合学习和中小项目；
- Boost.ASIO 1.70+：将 asio::awaitable 与 I/O 服务深度整合，天然支持线程池、定时器、socket 操作；
- libunifex（Facebook 开源，正推动进标准）：基于 sender/receiver 模型，更函数式、无状态、零开销，但学习曲线较陡。
选型关键看运行时约束和生态兼容性
不必纠结“用原生协程还是模拟 async/await”，而应明确实际需求：
- 如果已有 ASIO 基础设施，直接用 asio::awaitable 最省心，无需额外抽象层；
- 如果追求最小依赖、嵌入式或性能敏感场景，可手写轻量 awaitable 配合自定义 executor；
- 如果团队熟悉 .NET 风格编程，且不介意引入 cppcoro，它的 task + thread_pool 组合接近直觉；
- 若面向未来标准（C++26+），建议关注 unifex 的 sender/receiver，它正成为 std::execution 的事实基础。
错误认知：协程 = 自动并发 or 零成本异步
协程本身不并发，也不自动调度：
- co_await 只是让当前执行流暂停并移交控制权，是否切线程、何时恢复、在哪恢复，全由你写的 await_suspend 决定；
- 忘记在 await_suspend 中正确安排恢复（比如漏掉 executor.post()），会导致协程永远挂起；
- 所有栈变量在挂起时被保留在协程帧（heap 分配，除非启用 stackless 优化），不当使用可能引发内存泄漏或生命周期错误。
