当前位置：首页 > news >正文

C++20协程实战：从原理到异步IO编程的三大应用案例

news 2026/7/21 6:01:13

1. 项目概述：为什么C++20协程是异步IO的“游戏规则改变者”？

如果你和我一样，常年混迹在C++高性能服务端开发的一线，肯定对异步IO编程的复杂性深有体会。传统的基于回调（Callback）或Future/Promise的异步模型，代码逻辑被切割得支离破碎，状态管理困难，调试起来更是让人头疼。一个复杂的异步操作链，写出来就像一团“回调地狱”的意大利面，可读性和可维护性都大打折扣。

C++20标准引入的协程（Coroutines），在我看来，是近十年来C++语言层面最激动人心的特性之一，它为我们处理异步IO提供了一种全新的、更符合人类线性思维模式的编程范式。它不是什么库，而是语言核心支持的特性。简单来说，协程允许函数在执行过程中被挂起（suspend），稍后再从挂起点恢复（resume）执行，并且能保持挂起时的所有局部状态。这听起来是不是很像我们在写同步阻塞代码时的体验？是的，协程的目标就是让我们能用写同步代码的直观方式，去实现高性能的异步逻辑。

“轻松驾驭”这个词用在这里非常贴切。当你用协程重构异步IO代码时，你会发现那些令人望而生畏的回调嵌套消失了，取而代之的是清晰、顺序执行的代码流。这对于处理网络通信、文件读写、数据库查询等密集型IO操作来说，无疑是弯道超车的绝佳机会。本文将通过3个由浅入深的实战案例，带你从零开始，理解如何用C++20协程来驯服异步IO这头“猛兽”。无论你是正在为现有项目寻找性能与代码可读性的平衡点，还是准备在新项目中尝试前沿技术，相信这篇分享都能给你带来直接的启发和可复用的代码。

2. 核心概念与基础设施搭建

在深入案例之前，我们必须先打好地基。C++20的协程是“无栈协程”（Stackless Coroutines），这意味着它的挂起状态不依赖于独立的调用栈，而是由编译器在堆上分配一个“协程帧”（coroutine frame）来保存状态。这种设计效率极高，但同时也意味着我们需要理解几个关键组件。

2.1 理解协程的“三驾马车”

一个C++20协程函数，其返回类型必须满足“协程承诺类型”（Promise Type）的要求。这个类型定义了协程的行为。通常，我们会通过一个“Awaitable”类型来封装异步操作，而协程内部则使用co_await运算符来挂起并等待这个Awaitable完成。

协程句柄（coroutine_handle）：这是操作系统或运行时用来识别和恢复一个特定协程的令牌。你通常不会直接操作它，但它是一切的基础。
承诺类型（Promise Type）：这是协程的“大脑”。它决定了协程的返回对象（get_return_object）、初始挂起行为（initial_suspend）、最终挂起行为（final_suspend），以及如何处理未捕获的异常（unhandled_exception）。我们通常会自定义一个Promise类。
可等待体（Awaitable）：这是协程“等待”的对象。一个类型只要实现了await_ready,await_suspend,await_resume三个成员函数，它就是Awaitable。co_await expr中的expr必须是一个Awaitable，或者能通过operator co_await转换成Awaitable。

2.2 构建一个最简单的协程任务框架

为了不让案例被复杂的框架代码干扰，我们先搭建一个极简的、通用的协程任务模板Task。这个Task将作为我们所有案例中协程函数的返回类型。

#include <coroutine> #include <exception> #include <iostream> template<typename T> struct Task { // 内部定义的承诺类型，是协程的核心 struct promise_type { // 协程的返回值（通常存储在一个共享状态或直接存储） T value_; std::exception_ptr exception_; // 构造协程的返回对象（即Task本身） Task get_return_object() { // 从当前协程的承诺对象构造一个Task return Task{std::coroutine_handle<promise_type>::from_promise(*this)}; } // 协程开始时是否立即挂起？我们选择“不挂起”，让协程执行直到第一个co_await std::suspend_never initial_suspend() noexcept { return {}; } // 协程结束时（co_return或异常退出）是否挂起？ // 我们选择“挂起”，让外部有机会获取结果或处理异常 std::suspend_always final_suspend() noexcept { return {}; } // 处理协程内部的返回值 void return_value(T value) { value_ = std::move(value); } // 如果没有返回值（void特化），需要另一个版本，这里先省略 // 处理协程内部未捕获的异常 void unhandled_exception() { exception_ = std::current_exception(); } }; // Task对象持有一个协程句柄 std::coroutine_handle<promise_type> handle_; // 构造函数和析构函数 explicit Task(std::coroutine_handle<promise_type> h) : handle_(h) {} ~Task() { if (handle_) handle_.destroy(); } // 禁止拷贝，允许移动 Task(const Task&) = delete; Task& operator=(const Task&) = delete; Task(Task&& other) noexcept : handle_(other.handle_) { other.handle_ = nullptr; } Task& operator=(Task&& other) noexcept { if (this != &other) { if (handle_) handle_.destroy(); handle_ = other.handle_; other.handle_ = nullptr; } return *this; } // 等待这个Task完成，并获取结果（这是一个阻塞调用，仅用于示例） T get() { if (!handle_.done()) { handle_.resume(); // 恢复协程执行，直到它再次挂起或结束 } if (handle_.promise().exception_) { std::rethrow_exception(handle_.promise().exception_); } return std::move(handle_.promise().value_); } };

注意：这个Task模板的get()方法是阻塞的，在实际的异步框架（如asio）中，我们不会这样用。这里只是为了演示原理。真正的异步框架会提供自己的调度器（Scheduler）和co_await支持。

2.3 与异步IO库的桥梁：自定义Awaitable

异步IO库（如Boost.Asio）本身并不直接理解C++20协程。我们需要为它的异步操作（如async_read,async_write）创建Awaitable包装器。这是将协程与现有异步生态连接起来的关键一步。

以Asio的async_read_some为例，我们可以创建一个通用的Awaitable适配器：

#include <asio.hpp> using asio::ip::tcp; template<typename AsyncStream, typename MutableBuffer> struct AsyncReadAwaitable { AsyncStream& stream; MutableBuffer buffer; std::error_code ec; std::size_t bytes_transferred = 0; // 异步操作是否已经完成？如果完成，就不需要挂起。 bool await_ready() const noexcept { return false; } // 总是假设未完成，需要挂起 // 挂起协程，并启动异步操作。 // `h` 是当前协程的句柄，当异步操作完成时，我们需要恢复它。 void await_suspend(std::coroutine_handle<> h) { // 使用Asio的异步接口，并在完成回调中恢复协程 stream.async_read_some(buffer, [h, this](const std::error_code& error, std::size_t bytes) mutable { this->ec = error; this->bytes_transferred = bytes; h.resume(); // 关键：异步操作完成，恢复挂起的协程 }); } // 当协程恢复时，返回异步操作的结果。 std::size_t await_resume() { if (ec) { throw std::system_error(ec); // 将错误码转换为异常抛出 } return bytes_transferred; } };

有了这个AsyncReadAwaitable，我们就可以在协程里这样写，看起来完全是同步的：

Task<void> readFromSocket(tcp::socket& socket) { std::array<char, 1024> data; // 下面这行代码会挂起协程，直到数据读完，但不会阻塞线程！ std::size_t n = co_await AsyncReadAwaitable<tcp::socket, asio::mutable_buffer>{socket, asio::buffer(data)}; std::cout << "Read " << n << " bytes: " << std::string_view(data.data(), n) << std::endl; }

3. 案例一：协程化简易TCP回声服务器

第一个案例，我们用最经典的TCP回声服务器来感受协程带来的简洁性。服务器接受连接，然后为每个客户端创建一个协程来处理：读取数据，再原样写回去。

3.1 服务器主循环与协程分发

传统的Asio服务器需要为每个连接设置一个回调链。现在，我们可以用一个无限循环的accept协程，每接受一个连接，就“投递”一个处理协程到后台执行。

#include <asio/awaitable.hpp> #include <asio/co_spawn.hpp> #include <asio/detached.hpp> #include <asio/use_awaitable.hpp> using asio::ip::tcp; using asio::awaitable; using asio::co_spawn; using asio::detached; namespace this_coro = asio::this_coro; // 处理单个客户端连接的协程 awaitable<void> echo_session(tcp::socket socket) { try { char data[1024]; for (;;) { // co_await 等待异步读操作完成。use_awaitable是Asio提供的适配器，将异步操作转换为Awaitable。 std::size_t n = co_await socket.async_read_some(asio::buffer(data), asio::use_awaitable); // 读完后，继续等待异步写操作完成。 co_await async_write(socket, asio::buffer(data, n), asio::use_awaitable); } } catch (std::exception& e) { // 客户端断开连接或发生错误，协程自然结束。 std::cerr << "Echo session exception: " << e.what() << std::endl; } } // 监听并接受连接的协程 awaitable<void> echo_listener(tcp::acceptor& acceptor) { for (;;) { // 异步接受连接，挂起直到有新客户端连接 tcp::socket socket = co_await acceptor.async_accept(asio::use_awaitable); // 一旦有连接，立即“点火”启动一个处理协程，并与之分离（detached），让它独立运行。 // co_spawn 是Asio提供的，用于在指定的执行器（Executor）上启动一个协程。 co_spawn(acceptor.get_executor(), echo_session(std::move(socket)), detached); std::cout << "New client connected." << std::endl; } } int main() { asio::io_context io_context; tcp::acceptor acceptor(io_context, tcp::endpoint(tcp::v4(), 8080)); // 在主线程的io_context上启动监听协程 co_spawn(io_context, echo_listener(acceptor), detached); std::cout << "Echo server running on port 8080..." << std::endl; io_context.run(); // 启动事件循环 return 0; }

3.2 代码对比与优势分析

对比一下传统基于回调的Asio实现，你需要为async_accept、async_read_some、async_write分别编写lambda回调，并且要小心地传递socket对象和data缓冲区，确保它们的生命周期。在协程版本中，所有这些都消失了。socket和data是协程的局部变量，它们的生命周期与协程的执行周期完全绑定，由编译器自动管理，完全不用担心悬空引用或内存泄漏。

实操心得一：错误处理变得直观在回调模型中，错误通常通过error_code参数传递，需要在每个回调里检查。在协程中，我们可以直接使用asio::use_awaitable，它会在异步操作失败时抛出std::system_error异常。这样，我们就可以用熟悉的try-catch块来统一处理一个会话中的所有错误，逻辑集中，清晰得多。

注意事项一：理解co_spawn与执行器（Executor）co_spawn的第一个参数是Executor（这里是acceptor.get_executor()）。它决定了新协程在哪个线程上下文中被恢复和执行。如果你传入io_context.get_executor()，那么协程的恢复工作将由io_context.run()所在的线程池调度。正确使用执行器对于避免数据竞争和保证性能至关重要。通常，我们将IO相关的协程放在IO线程的执行器上，将CPU密集型计算放在独立的计算线程池执行器上。

4. 案例二：协程实现高性能HTTP请求抓取器

第二个案例，我们提升复杂度，实现一个并发抓取多个HTTP页面的小程序。这涉及到发起多个并发的TCP连接、发送HTTP GET请求、接收并解析响应头（为了简化，我们只读取响应体直到连接关闭）。协程使得管理这些并发的异步操作变得异常简单。

4.1 封装HTTP GET请求协程

我们先定义一个fetch_url协程，它负责与一个服务器完成整个HTTP交互。

awaitable<std::string> fetch_url(asio::io_context& io_context, const std::string& host, const std::string& port, const std::string& path) { tcp::socket socket(io_context); tcp::resolver resolver(io_context); // 1. 异步解析域名 auto endpoints = co_await resolver.async_resolve(host, port, asio::use_awaitable); // 2. 异步连接服务器 co_await asio::async_connect(socket, endpoints, asio::use_awaitable); // 3. 异步发送HTTP GET请求 std::string request = "GET " + path + " HTTP/1.1\r\n"; request += "Host: " + host + "\r\n"; request += "Connection: close\r\n\r\n"; co_await async_write(socket, asio::buffer(request), asio::use_awaitable); // 4. 异步读取响应 asio::streambuf response; std::error_code ec; // 循环读取，直到遇到EOF（连接关闭） while (ec != asio::error::eof) { co_await socket.async_read_some(response.prepare(1024), asio::redirect_error(asio::use_awaitable, ec)); response.commit(1024); } // 5. 忽略响应头，直接返回响应体（这是一个简陋的处理） std::istream is(&response); std::string header; while (std::getline(is, header) && header != "\r") {} // 跳过头部直到空行 std::string body((std::istreambuf_iterator<char>(is)), std::istreambuf_iterator<char>()); co_return body; }

4.2 使用`when_all`实现并发抓取

单个抓取是顺序的。要实现并发，我们需要同时启动多个fetch_url协程，并等待它们全部完成。Asio提供了asio::experimental::when_all来组合多个Awaitable。

#include <asio/experimental/awaitable_operators.hpp> using namespace asio::experimental::awaitable_operators; awaitable<void> fetch_multiple_pages(asio::io_context& io_context) { std::vector<std::tuple<std::string, std::string, std::string>> tasks = { {"www.example.com", "80", "/"}, {"www.boost.org", "80", "/"}, {"www.open-std.org", "80", "/"} }; // 启动所有抓取任务，它们将并发执行 std::vector<awaitable<std::string>> fetch_tasks; for (const auto& [host, port, path] : tasks) { fetch_tasks.push_back(fetch_url(io_context, host, port, path)); } // 使用 when_all 等待所有任务完成 // 注意：when_all 返回一个元组（tuple），里面是各个协程的结果。 auto results = co_await when_all(fetch_tasks.begin(), fetch_tasks.end()); int i = 0; for (const auto& [host, port, path] : tasks) { try { // std::get<i>(results) 获取第i个协程的结果（是一个awaitable，需要再次co_await获取值） // 但when_all返回的已经是结果值了，这里需要根据实际实现调整。以下为概念性代码。 std::string body = co_await std::get<i>(results); std::cout << "Fetched from " << host << path << ", size: " << body.size() << " bytes\n"; // 简单打印前100个字符 std::cout << "Preview: " << body.substr(0, std::min<size_t>(100, body.size())) << "...\n\n"; } catch (const std::exception& e) { std::cerr << "Failed to fetch from " << host << path << ": " << e.what() << std::endl; } ++i; } }

在主函数中，我们只需要co_spawn这个fetch_multiple_pages协程。

int main() { asio::io_context io_context; co_spawn(io_context, fetch_multiple_pages(io_context), detached); io_context.run(); return 0; }

4.3 性能与资源管理考量

这个并发抓取器虽然代码简洁，但性能可能比精心设计的回调版本更高吗？答案是：在逻辑复杂度相同的情况下，性能是等效的。因为底层仍然是Asio的事件驱动模型，协程只是提供了一种更优的代码组织方式，并没有增加额外的开销。所有的挂起和恢复操作，在编译后都转化为了对回调函数和状态机的操作，效率极高。

实操心得二：警惕协程的“隐蔽”阻塞虽然co_await挂起的是协程而非线程，但协程内部如果执行了阻塞操作（如调用阻塞的IO、std::this_thread::sleep_for），那么执行该协程的线程就会被阻塞，从而影响整个事件循环的吞吐量。在协程中，对于需要延迟的操作，应该使用asio::steady_timer并co_await它的async_wait。

注意事项二：协程的生命周期与内存每个协程都有一个在堆上分配的协程帧。协程帧的生命周期从协程首次挂起开始（initial_suspend返回suspend_always时），到协程句柄被显式销毁（handle.destroy()）或协程运行结束且final_suspend返回suspend_never时自动销毁。在我们的Task模板中，析构函数调用了destroy()。在Asio的awaitable中，生命周期由Asio内部管理。务必确保协程句柄或管理它的对象（如Task）的生命周期足够长，避免协程帧泄漏。

5. 案例三：构建带流量控制的协程化管道（Pipeline）

第三个案例，我们设计一个更复杂的模式：管道（Pipeline）。想象一个数据处理场景，比如从网络读取日志，经过压缩、加密，最后写入磁盘。每个步骤都可以是一个协程，它们通过线程安全的队列连接起来，形成生产者-消费者模式。协程让每个阶段的逻辑独立且清晰，而管道本身则优雅地处理了背压（Backpressure）——当消费者处理慢时，生产者会自动被挂起。

5.1 实现一个协程友好的无锁队列

首先，我们需要一个能在协程间安全传递数据的队列。它需要提供async_push和async_pop这样的Awaitable接口。

template<typename T> class AsyncQueue { public: // 尝试推送数据，如果队列满则挂起协程，直到有空间。 awaitable<void> async_push(T value) { while (true) { { std::unique_lock lock(mutex_); if (queue_.size() < max_size_) { queue_.push(std::move(value)); not_empty_.notify_one(); co_return; } // 队列满，等待有空间 push_cv_.wait(lock); } co_await asio::detail::post_coroutine(asio::use_awaitable); // 让出执行权，避免忙等待 } } // 尝试弹出数据，如果队列空则挂起协程，直到有数据。 awaitable<T> async_pop() { while (true) { { std::unique_lock lock(mutex_); if (!queue_.empty()) { T value = std::move(queue_.front()); queue_.pop(); not_full_.notify_one(); co_return value; } // 队列空，等待有数据 pop_cv_.wait(lock); } co_await asio::detail::post_coroutine(asio::use_awaitable); } } private: std::queue<T> queue_; std::mutex mutex_; std::condition_variable push_cv_, pop_cv_, not_empty_, not_full_; size_t max_size_ = 100; // 队列容量，用于流量控制 };

注意：上述实现使用了互斥锁和条件变量，在协程中阻塞会阻塞底层线程。更高效的做法是实现一个完全无锁的、基于原子操作和自旋等待的队列，或者利用Asio的post和defer来调度，避免线程阻塞。这里为了概念清晰，使用了简化模型。

5.2 组装三阶段处理管道

假设我们有三个阶段：生产者（模拟网络读取）、处理器（模拟数据转换）、消费者（模拟写入）。

// 阶段1：生产者协程 awaitable<void> producer_stage(AsyncQueue<std::string>& queue) { for (int i = 0; i < 10; ++i) { std::string data = "DataBlock_" + std::to_string(i); std::cout << "[Producer] Generating: " << data << std::endl; co_await queue.async_push(std::move(data)); // 模拟生产耗时 asio::steady_timer timer(co_await this_coro::executor); timer.expires_after(std::chrono::milliseconds(100)); co_await timer.async_wait(asio::use_awaitable); } // 发送结束信号 co_await queue.async_push(""); // 空字符串作为结束标志 } // 阶段2：处理器协程（转换数据） awaitable<void> processor_stage(AsyncQueue<std::string>& in_queue, AsyncQueue<std::string>& out_queue) { while (true) { std::string data = co_await in_queue.async_pop(); if (data.empty()) { // 收到结束信号 co_await out_queue.async_push(""); // 传递结束信号 break; } std::string processed_data = "[Processed] " + data; std::cout << "[Processor] Processing: " << data << " -> " << processed_data << std::endl; // 模拟处理耗时 asio::steady_timer timer(co_await this_coro::executor); timer.expires_after(std::chrono::milliseconds(150)); co_await timer.async_wait(asio::use_awaitable); co_await out_queue.async_push(std::move(processed_data)); } } // 阶段3：消费者协程 awaitable<void> consumer_stage(AsyncQueue<std::string>& queue) { while (true) { std::string data = co_await queue.async_pop(); if (data.empty()) { // 收到结束信号 break; } std::cout << "[Consumer] Writing: " << data << std::endl; // 模拟消费耗时 asio::steady_timer timer(co_await this_coro::executor); timer.expires_after(std::chrono::milliseconds(200)); co_await timer.async_wait(asio::use_awaitable); } std::cout << "[Consumer] Pipeline finished." << std::endl; } // 主协程：组装并运行管道 awaitable<void> run_pipeline(asio::io_context& io_context) { AsyncQueue<std::string> queue1, queue2; // 并发启动三个阶段的协程 auto prod = producer_stage(queue1); auto proc = processor_stage(queue1, queue2); auto cons = consumer_stage(queue2); // 等待所有阶段完成（这里简化处理，实际可能需要更精细的同步） co_await prod; co_await proc; co_await cons; }

5.3 管道模式的优势与调试技巧

这个管道模式清晰地分离了关注点。每个阶段只关心自己的输入队列和输出队列，逻辑纯粹。流量控制是自动的：如果消费者慢，queue2会满，导致processor_stage在async_push到queue2时挂起，进而导致queue1无法被消费而变满，最终使producer_stage挂起。整个系统平滑地慢下来，而不会丢失数据或耗尽内存。

实操心得三：使用协程调试器或大量日志调试协程比调试线性代码更复杂，因为执行流可能在不同协程间跳转。一个有效的方法是大量使用日志，在每个co_await前后和关键逻辑点打印协程ID（可以通过std::this_thread::get_id()结合自定义标识）和状态。另外，一些IDE（如Visual Studio 2019+）和调试器已经开始提供对C++20协程的有限支持，可以单步跟踪协程的挂起和恢复。

注意事项三：避免在协程中持有锁跨越挂起点这是协程编程中的一个重要陷阱。如果在协程中持有一个互斥锁（std::mutex），然后在持有锁的情况下执行了co_await，协程被挂起，锁依然被持有。这可能导致其他需要该锁的协程或线程被长时间阻塞，甚至引发死锁。解决方案是使用std::unique_lock等RAII锁，并确保在co_await之前锁的作用域已经结束。对于必须保护跨越挂起点的数据，考虑使用无锁数据结构或Asio的strand来序列化访问。

6. 进阶话题与性能调优指南

掌握了基本用法后，要想在生产环境中用好协程，还需要关注一些进阶话题和性能细节。

6.1 自定义分配器与协程帧内存优化

默认情况下，协程帧通过全局的operator new分配。对于高性能应用，频繁的协程创建/销毁可能导致内存碎片和分配器争用。我们可以通过自定义承诺类型的operator new和operator delete来使用内存池或栈分配。

struct my_promise_type { // ... 其他成员函数 ... // 自定义内存分配 void* operator new(std::size_t size) { return my_memory_pool::allocate(size); // 使用自定义内存池 } void operator delete(void* ptr, std::size_t size) { my_memory_pool::deallocate(ptr, size); } };

对于生命周期极短、大小固定的协程，甚至可以考虑在栈上分配协程帧，但这需要非常精细的控制和对ABI的深入理解，一般不建议初学者尝试。

6.2 与现有线程池及调度器集成

Asio的io_context本身就是一个调度器。但在大型应用中，你可能希望将CPU密集型计算任务卸载到独立的线程池，避免阻塞IO线程。这需要你创建额外的asio::thread_pool，并使用co_spawn指定不同的执行器。

asio::io_context io_ctx; // IO线程，处理网络 asio::thread_pool compute_pool(4); // 计算线程池，4个线程 awaitable<void> io_intensive_task() { // ... 网络IO操作，使用 co_await ... } awaitable<void> cpu_intensive_task() { // 将计算任务派发到计算线程池 co_await asio::post(compute_pool, asio::use_awaitable); // 接下来的代码将在计算线程池中执行 int result = perform_heavy_computation(); // 可能需要将结果传回IO线程进行后续网络操作 co_await asio::post(io_ctx.get_executor(), asio::use_awaitable); co_await send_result_over_network(result); }

6.3 协程的取消操作

协程应该支持取消，这在处理超时或用户中断时非常有用。Asio的awaitable与cancellation_signal集成。你可以为一系列协程操作设置一个取消信号，并在需要时触发它。

asio::cancellation_signal cancel_signal; awaitable<void> cancellable_task(asio::io_context& io_context) { asio::steady_timer timer(io_context); timer.expires_after(std::chrono::seconds(5)); // 等待定时器或取消信号，谁先到就继续执行 auto [ec] = co_await timer.async_wait( asio::experimental::as_tuple(asio::bind_cancellation_slot( cancel_signal.slot(), asio::use_awaitable)) ); if (cancel_signal.slot().is_connected() && cancel_signal.slot().cancelled() != asio::cancellation_type::none) { std::cout << "Task was cancelled!\n"; co_return; } if (!ec) { std::cout << "Timer finished!\n"; } } // 在另一个地方，可以触发取消 // cancel_signal.emit(asio::cancellation_type::all);

7. 常见陷阱、调试技巧与社区资源

即使理解了原理，在实际编码中依然会遇到不少坑。这里记录一些我踩过的雷和总结的经验。

7.1 典型编译错误与排查

co_await不可用：确保你等待的表达式是Awaitable类型。对于第三方库的异步函数，你需要为其创建适配器或使用库提供的适配器（如Asio的asio::use_awaitable）。
返回类型错误：协程函数的返回类型必须包含一个合法的promise_type。仔细检查你的Task或awaitable的promise_type定义是否完整，特别是get_return_object、initial_suspend、final_suspend、return_void/return_value和unhandled_exception这几个函数。
忘记处理异常：如果在协程中抛出异常且未被捕获，并且promise_type的unhandled_exception()没有实现或实现不当，程序会直接调用std::terminate。务必在unhandled_exception中保存异常（例如用std::current_exception()），并在await_resume或get()中重新抛出。

7.2 运行时问题与调试

协程泄漏（内存泄漏）：确保每个协程句柄最终都被销毁。如果你的协程因为循环引用或意外路径导致final_suspend返回了suspend_always且句柄未被保存和销毁，协程帧就会泄漏。使用智能指针管理协程句柄或依赖RAII包装器（如我们的Task析构函数）是好的实践。
数据竞争：虽然一个协程在某个时刻只在一个线程上执行，但多个协程可能并发访问共享数据。使用互斥锁、原子变量或Asio的strand来保护共享状态。记住注意事项三，避免持锁跨越挂起点。
栈溢出？不，是协程帧溢出：无栈协程虽然不占用传统调用栈，但协程帧本身在堆上分配。如果递归地co_await另一个协程（尤其是可能同步完成的协程），虽然不会栈溢出，但可能导致深度嵌套的协程帧分配。对于深度递归算法，仍需考虑转换为迭代形式。

7.3 学习资源与社区

编译器支持：确保你使用足够新的编译器（如GCC 11+, Clang 14+, MSVC 2019 16.8+）并开启C++20标准（-std=c++20//std:c++20）。
Asio官方文档：Boost.Asio和Standalone Asio的文档是学习协程集成的最佳实践来源，特别是asio::awaitable、co_spawn和use_awaitable的用法。
CppCoro库：这是一个由微软开发的开源库，提供了task<>、generator<>、async_scope等更多协程工具，可以作为学习和补充。
社区讨论：/r/cpp、CppCon会议视频以及各大C++博客是获取前沿实践和解决疑难杂症的好地方。