1. 项目概述为什么我们需要在C里谈论协程如果你写过网络服务、游戏引擎或者任何需要处理大量并发I/O的程序肯定对“回调地狱”和“线程切换开销”这两个词深恶痛绝。传统的多线程模型每个连接一个线程听起来简单但线程创建、销毁和上下文切换的成本在连接数上万时就成了性能瓶颈。而基于回调的异步模型代码被拆得七零八落逻辑跳来跳去调试起来像在迷宫里找路。协程Coroutines就是为了解决这些问题而生的。它不是C的新发明在Python、Go、Kotlin等语言中早已是并发编程的利器。简单说协程是一种用户态的、更轻量的“线程”它允许函数在执行过程中被挂起Suspend稍后再从挂起的地方恢复Resume并且这个挂起和恢复的操作完全由程序员控制不涉及操作系统的内核调度。这意味着你可以用看似同步的、顺序的代码写出高性能的异步程序。C20标准正式将协程引入语言核心这是一件大事。它标志着C在现代化并发编程范式上迈出了关键一步。但C的协程被很多人称为“给库作者用的低阶原语”因为它本身只提供了最基础的机制三个关键字co_await,co_yield,co_return并没有像Go的goroutine那样开箱即用的高级抽象。理解这套机制就像是拿到了乐高积木最基础的零件虽然一开始有点懵但一旦掌握你就能搭建出任何你想要的并发结构。所以这篇内容适合谁如果你是中级以上的C开发者对多线程和异步编程有基本了解并且对性能有追求或者你正在维护或开发一个高性能网络库、游戏服务器、数据处理流水线那么深入理解C协程将是你工具箱里的一件利器。它能帮你写出更简洁、更高效、更易维护的并发代码。2. 协程的核心概念从“函数”到“可暂停的函数”要理解协程我们得先忘掉“函数调用即执行到底”的固有观念。一个普通的函数调用入口是固定的执行流程也是确定的执行完毕栈帧销毁生命周期结束。协程则不同它更像一个有状态的对象。2.1 协程的生命周期与关键组件当一个函数被声明为协程即函数体内使用了co_await,co_yield,co_return中的任何一个编译器就会对它进行“魔法改造”。这个改造围绕着几个核心对象展开理解它们的关系是理解C协程的关键。协程帧Coroutine Frame这是协程的“身体”。它是一个在堆上通常分配的内存块里面保存了协程的全部状态。包括局部变量包括参数。挂起点当前执行到了哪里。promise对象。协程句柄coroutine_handle。 普通函数的局部变量在栈上函数返回就没了。协程的局部变量在协程帧里即使挂起这些变量也依然存在等待恢复。这是协程能“暂停”并“继续”的物质基础。Promise对象这是协程的“控制中心”或“内部接口”。编译器会根据协程的返回类型来定位和创建对应的promise_type。promise对象负责协程的初始化和最终清理。产生值对于生成器co_yield或返回值对于co_return。处理未捕获的异常。 你可以把promise想象成协程与外部调用者之间的一个协议管理器。协程句柄std::coroutine_handle这是协程的“遥控器”。它是一个非拥有的指针指向协程帧。通过句柄我们可以从外部恢复resume()协程或者销毁destroy()它。句柄是我们在外部与一个特定协程实例交互的主要手段。Awaitable对象与Awaiter这是实现“挂起”语义的核心。co_await expr中的expr必须是一个Awaitable可等待对象。编译器会向这个Awaitable请求一个Awaiter对象。Awaiter有三个关键方法await_ready()询问“准备好了吗”。如果返回true协程就不挂起直接继续执行。await_suspend(std::coroutine_handle h)在协程决定挂起时调用。参数h是当前协程的句柄。这里你可以做任何事比如将句柄h存入某个任务队列等数据就绪后再调用h.resume()。这是实现异步调度的核心钩子。await_resume()当协程恢复时调用它的返回值就是co_await表达式的结果。注意很多初学者会混淆Awaitable和Awaiter。简单记法Awaitable是“可以被co_await的东西”而Awaiter是Awaitable提供的、真正执行挂起/恢复逻辑的“工作者”。一个Awaitable可以返回它自己作为Awaiter即Awaitable同时是Awaiter也可以返回另一个不同的Awaiter对象。2.2 编译器为我们做了什么协程的展开魔法当我们调用一个协程函数时编译器生成的伪代码大致如下MyReturnType my_coroutine(Args...) { // 1. 在堆上分配协程帧大小足以容纳参数、局部变量、promise、句柄等。 auto* frame operator new(sizeof(coroutine_frame)); // 2. 在帧中构造 promise 对象: promise_type p(frame, args...); // 3. 通过 p.get_return_object() 获取返回给调用者的对象通常包含或能生成句柄。 MyReturnType return_obj p.get_return_object(); // 4. 协程体开始执行但可能立即挂起 try { // 5. co_await p.initial_suspend(); 初始挂起点 // 根据 initial_suspend() 返回的 awaiter 决定是立即执行还是挂起。 // 6. 执行用户编写的协程函数体... // 遇到 co_await, co_yield, co_return 会进行相应的挂起/恢复逻辑。 // 7. 协程体执行完毕co_await p.final_suspend(); 最终挂起点 } catch (...) { p.unhandled_exception(); // 处理未捕获异常 } // 8. 协程帧的清理可能由 promise 或外部通过句柄 destroy 触发 // 注意final_suspend 后协程通常不再被恢复但帧可能还未销毁。 }从这个流程可以看出协程的创建比普通函数调用昂贵因为它涉及堆内存分配。因此对于极高性能的场景可能需要自定义内存分配器来管理协程帧。同时initial_suspend和final_suspend给了我们控制协程启动和结束行为的入口。3. 从零开始实现一个最简单的生成器Generator理论说了很多我们动手实现一个最经典的协程用例生成器。它用于惰性地产生一个序列。C标准库目前截至C23还没有提供标准的生成器但我们可以自己实现一个简化版这能帮助我们串联起所有概念。3.1 定义Promise类型和返回类型生成器的核心是co_yield value。co_yield expr在编译器看来大致等价于co_await promise.yield_value(expr)。所以我们的promise_type需要实现yield_value方法。#include coroutine #include exception #include iostream // 1. 定义我们的生成器返回类型模板 templatetypename T struct Generator { // 2. 内部定义 promise_type这是编译器寻找的接口 struct promise_type { T m_value; // 用于存储 yield 出来的值 // 3. 必须实现的接口方法 Generator get_return_object() { // 通过 promise 对象自身构造一个 Generator 返回给调用者 return Generator{ std::coroutine_handlepromise_type::from_promise(*this) }; } // 4. 初始挂起我们选择“立即挂起”让调用者控制第一次恢复 std::suspend_always initial_suspend() noexcept { return {}; } // 5. 最终挂起协程体执行完后永远挂起由调用者销毁帧 std::suspend_always final_suspend() noexcept { return {}; } // 6. 处理 yield 值 std::suspend_always yield_value(T value) noexcept { m_value std::move(value); return {}; // 返回一个总是挂起的 awaiter } // 7. 处理 co_return; (无返回值) void return_void() noexcept {} // 8. 异常处理 void unhandled_exception() { std::terminate(); } }; // Generator 类自身的成员 std::coroutine_handlepromise_type m_handle; // 构造函数和析构函数 explicit Generator(std::coroutine_handlepromise_type handle) : m_handle(handle) {} ~Generator() { if (m_handle) { m_handle.destroy(); // 负责销毁协程帧 } } // 禁用拷贝允许移动 Generator(const Generator) delete; Generator operator(const Generator) delete; Generator(Generator other) noexcept : m_handle(std::exchange(other.m_handle, nullptr)) {} Generator operator(Generator other) noexcept { if (this ! other) { if (m_handle) m_handle.destroy(); m_handle std::exchange(other.m_handle, nullptr); } return *this; } // 迭代器接口让 Generator 可以用范围 for 循环 struct sentinel {}; struct iterator { std::coroutine_handlepromise_type m_handle; bool operator!(sentinel) const { return !m_handle.done(); } iterator operator() { m_handle.resume(); // 恢复协程执行到下一个 yield 或结束 return *this; } T operator*() const { return m_handle.promise().m_value; // 获取当前 yield 的值 } }; iterator begin() { if (m_handle) { m_handle.resume(); // 第一次调用 begin() 时恢复协程 } return iterator{ m_handle }; } sentinel end() { return {}; } };3.2 使用我们的Generator现在我们可以用这个Generator来写一个协程函数了。Generatorint range(int start, int end, int step 1) { for (int i start; i end; i step) { co_yield i; // 每次 yield协程挂起返回一个值 } // 函数结束隐含 co_return; } int main() { std::cout Range generator: ; for (int num : range(1, 10, 2)) { // 这里会触发 begin()/end() 迭代 std::cout num ; } std::cout \n; // 手动控制版本 std::cout Manual control: ; auto gen range(20, 25); auto it gen.begin(); // 第一次 resume执行到第一个 yield while (it ! gen.end()) { std::cout *it ; it; // 再次 resume执行到下一个 yield 或结束 } std::cout \n; return 0; }输出应该是Range generator: 1 3 5 7 9 Manual control: 20 21 22 23 24实操心得在实现promise_type时initial_suspend()返回std::suspend_always是一个常见且安全的选择。这保证了协程在首次被调用时不会立即执行函数体而是将控制权交还给调用者。调用者通过Generator的begin()或手动resume()决定何时启动它。如果返回std::suspend_never协程会一直执行到第一个真正的挂起点如co_yield这可能不符合生成器“惰性求值”的预期。3.3 关键点解析get_return_object这个方法在协程帧和promise构造好后、任何挂起之前调用。它返回的对象这里是Generator就是协程函数调用如range(1,10,2)的返回值。这个对象必须提供一种方式让外部能控制协程通常就是保存一个协程句柄。std::suspend_always/std::suspend_never这是标准库提供的两个最简单的Awaitable也是Awaiter。suspend_always的await_ready()永远返回false所以协程总会在此挂起。suspend_never则永远返回true协程永不在此挂起。yield_value它接收co_yield后面的表达式结果将其存储起来这里是存入m_value然后返回一个决定是否挂起的Awaiter。我们返回suspend_always这样每次yield后协程都会挂起等待外部resume。资源管理Generator类管理着协程句柄的生命周期。在析构函数中调用handle.destroy()至关重要否则协程帧会内存泄漏。移动语义的实现确保了资源所有权的正确转移。迭代器适配通过实现begin()和end()我们让Generator支持了C11的范围for循环这大大提升了易用性。在begin()里我们进行了第一次resume()驱动协程运行到第一个yield点。4. 深入co_await构建一个简单的异步任务Task生成器展示了co_yield的用法但协程更强大的能力在于co_await它用于等待一个异步操作完成。我们来构建一个极简的Task用于表示一个在未来某个时刻产生结果的异步计算。4.1 设计一个支持链式等待的Task我们希望实现这样的效果Taskint async_compute() { int result co_await some_async_work(); // 等待一个异步操作 co_return result * 2; } Task main_task() { int value co_await async_compute(); // 等待另一个Task std::cout Got value: value std::endl; }为了实现co_await一个Task这个Task本身必须是一个Awaitable。同时为了能co_return一个值我们的promise_type需要实现return_value方法。#include coroutine #include future #include iostream #include thread #include chrono templatetypename T void struct Task { struct promise_type; using handle_type std::coroutine_handlepromise_type; struct promise_type { std::variantstd::monostate, T, std::exception_ptr m_result; // 存储结果或异常 std::coroutine_handle m_continuation; // 等待此Task完成的后续协程 Task get_return_object() { return Task{ handle_type::from_promise(*this) }; } std::suspend_always initial_suspend() noexcept { return {}; } // final_suspend 是关键 auto final_suspend() noexcept { struct FinalAwaiter { bool await_ready() noexcept { return false; } // 总是挂起 // 当本协程结束时恢复正在等待它的那个协程即m_continuation void await_suspend(handle_type h) noexcept { auto promise h.promise(); if (promise.m_continuation) { promise.m_continuation.resume(); } } void await_resume() noexcept {} }; return FinalAwaiter{}; } void return_value(T value) { m_result.template emplace1(std::move(value)); } void unhandled_exception() { m_result.template emplace2(std::current_exception()); } // 使 Task 自身成为 Awaitable 的接口 auto get_awaiter() { struct TaskAwaiter { promise_type m_promise; bool await_ready() const noexcept { // 检查结果是否已经就绪对于已经完成的Task return m_promise.m_result.index() ! 0; } // 当 co_await 一个未完成的Task时将当前协程保存为后续 void await_suspend(std::coroutine_handle awaiting_coro) noexcept { m_promise.m_continuation awaiting_coro; } // 当Task完成被恢复后取出结果或抛出异常 T await_resume() { if (m_promise.m_result.index() 2) { std::rethrow_exception(std::get2(m_promise.m_result)); } return std::get1(m_promise.m_result); } }; return TaskAwaiter{*this}; } }; handle_type m_handle; explicit Task(handle_type h) : m_handle(h) {} ~Task() { if (m_handle) m_handle.destroy(); } Task(const Task) delete; Task operator(const Task) delete; Task(Task other) noexcept : m_handle(std::exchange(other.m_handle, nullptr)) {} Task operator(Task other) noexcept { if (this ! other) { if (m_handle) m_handle.destroy(); m_handle std::exchange(other.m_handle, nullptr); } return *this; } // 使 Task 可被 co_await auto operator co_await() { return m_handle.promise().get_awaiter(); } }; // void 特化版本处理无返回值的Task template struct Taskvoid::promise_type { std::exception_ptr m_exception; std::coroutine_handle m_continuation; Task get_return_object() { return Task{ handle_type::from_promise(*this) }; } std::suspend_always initial_suspend() noexcept { return {}; } auto final_suspend() noexcept { struct FinalAwaiter { bool await_ready() noexcept { return false; } void await_suspend(handle_type h) noexcept { if (h.promise().m_continuation) { h.promise().m_continuation.resume(); } } void await_resume() noexcept {} }; return FinalAwaiter{}; } void return_void() {} void unhandled_exception() { m_exception std::current_exception(); } auto get_awaiter() { struct TaskAwaiter { promise_type m_promise; bool await_ready() const noexcept { return false; } // 简化处理总是未就绪 void await_suspend(std::coroutine_handle awaiting_coro) noexcept { m_promise.m_continuation awaiting_coro; } void await_resume() { if (m_promise.m_exception) std::rethrow_exception(m_promise.m_exception); } }; return TaskAwaiter{*this}; } };4.2 使用Task模拟异步操作为了测试我们创建一个模拟的异步操作它在一个单独的线程中睡眠一段时间后完成。#include functional // 一个简单的线程池模拟单线程用于演示 struct SimpleExecutor { void post(std::functionvoid() work) { std::thread([work std::move(work)]() { std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 模拟耗时I/O work(); }).detach(); } } executor; // 一个自定义的Awaitable用于模拟异步工作 struct AsyncWork { int m_value; bool await_ready() const { return false; } // 总是未就绪需要挂起 void await_suspend(std::coroutine_handle h) { // 将恢复协程的工作提交到执行器 executor.post([h]() mutable { std::cout [AsyncWork] Done on thread: std::this_thread::get_id() std::endl; h.resume(); // 在另一个线程恢复协程 }); } int await_resume() const { std::cout [AsyncWork] Resumed, returning value. std::endl; return m_value; } }; // 使用我们定义的Task和AsyncWork Taskint some_async_work() { std::cout [some_async_work] Started on thread: std::this_thread::get_id() std::endl; int result co_await AsyncWork{42}; // 挂起等待异步操作完成 std::cout [some_async_work] Resumed on thread: std::this_thread::get_id() std::endl; co_return result 10; } Task main_task() { std::cout [main_task] Started on thread: std::this_thread::get_id() std::endl; try { int value co_await some_async_work(); // 挂起等待子Task完成 std::cout [main_task] Got value: value std::endl; } catch (...) { std::cout [main_task] Exception caught. std::endl; } } int main() { auto task main_task(); // 创建根Task此时协程挂起在initial_suspend auto handle task.m_handle; handle.resume(); // 启动根协程它会执行到第一个co_await并挂起 // 此时异步操作已在后台线程进行 std::this_thread::sleep_for(std::chrono::milliseconds(500)); // 等待异步完成 // 注意我们的简易执行器会在异步完成后自动恢复对应的协程。 // 更完善的框架需要一个事件循环来驱动所有恢复操作。 return 0; }运行这个程序你可能会看到类似以下的输出线程ID会不同[main_task] Started on thread: 140735680332672 [some_async_work] Started on thread: 140735680332672 [AsyncWork] Done on thread: 123145557835776 [AsyncWork] Resumed, returning value. [some_async_work] Resumed on thread: 123145557835776 [main_task] Got value: 52注意事项这个例子为了清晰做了大量简化。一个生产级的异步任务框架需要处理更复杂的问题比如一个Task被多个协程等待即m_continuation需要是个链表、执行器的调度策略如何将恢复的工作post到合适的线程、协程帧的内存分配优化、取消操作的支持等。final_suspend返回的Awaiter是链式恢复的关键它确保了当一个协程完成时能自动恢复正在等待它的父协程从而形成调用链。4.3co_await工作流程详解当我们写下int result co_await some_async_work();时编译器会执行以下步骤计算some_async_work()表达式得到一个Taskint对象task。因为Task定义了operator co_await()所以调用task.operator co_await()得到一个TaskAwaiter对象awaiter。调用awaiter.await_ready()。在我们的实现里如果Task未完成结果未就绪返回false。因为await_ready()返回false协程需要挂起。调用awaiter.await_suspend(current_handle)其中current_handle是当前正在执行co_await的这个协程的句柄。在TaskAwaiter::await_suspend中我们将这个句柄current_handle保存到了被等待Task的promise的m_continuation成员中。这一步完成了“订阅”告诉被等待的Task“你完成的时候记得恢复我current_handle”。当前协程挂起控制权返回到它的恢复者可能是外部调用resume的地方也可能是它的父协程的final_suspend逻辑。当被等待的Task完成即执行到co_return时会进入其final_suspend。FinalAwaiter::await_suspend被调用它检查m_continuation如果非空就调用m_continuation.resume()。这一步完成了“通知”恢复之前等待它的那个协程。被恢复的协程即我们原来的协程从挂起点继续执行调用awaiter.await_resume()来获取Task的结果或抛出异常并将这个结果赋值给result变量。这个过程完美地实现了异步操作的“订阅-通知”模式而所有繁琐的回调注册和调用都被隐藏在了co_await关键字背后我们写出的代码是顺序的、直观的。5. 协程的实战技巧与常见陷阱理解了基本概念和简单实现后在实际项目中使用协程还需要注意以下关键点。5.1 内存分配优化协程帧默认在堆上分配对于高频创建销毁的协程如处理海量短连接这可能成为性能瓶颈。C协程设计时考虑到了这一点允许我们自定义协程帧的分配与释放。promise_type可以重载operator new和operator delete。更强大的是我们可以通过promise_type的get_return_object_on_allocation_failure()静态成员函数来处理分配失败虽然现代系统很少见或者更常见的使用std::allocator_arg和自定义的allocator。struct MyPromise { // 自定义内存分配 void* operator new(std::size_t size) { std::cout Allocating coroutine frame of size: size std::endl; // 可以从内存池、栈空间或特定区域分配 return ::operator new(size); } void operator delete(void* ptr, std::size_t size) { std::cout Deallocating coroutine frame of size: size std::endl; ::operator delete(ptr); } // ... 其他 promise 成员 ... };对于极致性能场景可以考虑将小协程分配到栈上通过alloca或预先分配的缓冲区但这需要非常小心地管理生命周期确保协程帧在挂起期间不会被过早销毁。5.2 异常安全协程中的异常传播与普通函数略有不同。如果协程体内抛出异常且未被捕获unhandled_exception()会被调用。你应该在此函数中将异常存储起来例如用std::current_exception()然后在await_resume()或Task的取值函数中重新抛出。void unhandled_exception() { m_exception std::current_exception(); // 存储异常 } // 在 await_resume 或 value() 函数中 if (m_exception) { std::rethrow_exception(m_exception); }一个重要陷阱如果异常在co_await表达式的await_suspend调用之后、await_resume调用之前抛出那么这个异常会在等待此协程的那个协程即m_continuation恢复时在其await_resume中抛出。我们的Task实现通过将异常存储在promise中并在await_resume里检查正确处理了这种情况。5.3 生命周期管理悬挂引用与Use-after-free这是协程编程中最容易出错的地方。协程帧的生命周期可能比某些对象的生命周期更长。Generatorstd::string_view problematic() { std::string local_str Hello; co_yield local_str; // 危险yield 了一个局部变量的视图 // 协程在此挂起。当外部迭代器恢复时local_str 已经销毁 } Generatorint capture_by_reference_bad() { int local_val 42; auto lambda []() - int { return local_val; }; co_yield lambda(); // 同样危险lambda捕获了局部变量的引用 }黄金法则确保co_yield或co_return返回的值其生命周期长于协程帧的挂起时间。对于指针、引用、视图如string_view要格外小心。通常的解决方案是按值传递co_yield std::string(local_str)生成一个副本。将数据存储在协程帧中将需要持久化的数据作为协程函数的参数或成员变量如果协程是lambda或类的成员函数它们会存储在协程帧里。使用智能指针对于堆上数据使用std::shared_ptr管理所有权。5.4 与现有异步库集成以asio为例许多现有的异步I/O库如Boost.Asio已经提供了对C20协程的支持。它们通常提供了现成的Awaitable对象。#include boost/asio.hpp #include boost/asio/use_awaitable.hpp namespace asio boost::asio; asio::awaitablevoid async_echo_session(asio::ip::tcp::socket socket) { try { char data[1024]; for (;;) { // co_await 一个 asio 的异步读操作语法非常简洁 std::size_t n co_await socket.async_read_some(asio::buffer(data), asio::use_awaitable); // co_await 一个 asio 的异步写操作 co_await async_write(socket, asio::buffer(data, n), asio::use_awaitable); } } catch (std::exception e) { std::cerr Echo session error: e.what() std::endl; } } asio::awaitablevoid async_listen(asio::io_context io_context) { auto executor co_await asio::this_coro::executor; asio::ip::tcp::acceptor acceptor(executor, {asio::ip::tcp::v4(), 55555}); for (;;) { // 接受新连接也是一个可等待的操作 asio::ip::tcp::socket socket co_await acceptor.async_accept(asio::use_awaitable); // 为每个连接创建一个新的协程协程帧独立 asio::co_spawn(executor, async_echo_session(std::move(socket)), asio::detached); } }asio::use_awaitable是一个完成令牌Completion Token它告诉Asio将异步操作适配成一个可以被co_await的Awaitable对象。asio::awaitableT是Asio库提供的类似我们之前实现的TaskT的返回类型。通过asio::co_spawn可以将一个协程“启动”到指定的执行器上运行。这种集成让基于协程的异步网络编程变得异常清晰。6. 调试与性能分析协程的调试比普通函数更复杂因为执行流会在挂起点跳跃。Visual Studio、GDB等现代调试器对C20协程的支持正在逐步完善。查看协程状态在调试器中你可以查看协程句柄coroutine_handle并检查其.done()方法来判断协程是否已执行完毕。你还可以尝试访问协程帧内部的变量但这需要知道帧的具体布局比较困难。堆栈跟踪当协程挂起时它的调用栈并不像线程那样完整保存在操作系统内核中。传统的基于线程的堆栈遍历工具可能无法显示完整的协程调用链。你需要依赖日志或专门的协程感知调试工具。性能分析使用诸如perf、VTune等性能分析工具时注意区分协程的“活跃”时间和“挂起”时间。协程挂起时几乎不消耗CPU。分析的重点应放在协程恢复后的执行逻辑上以及协程帧分配/销毁的开销。一个实用的调试技巧是在自定义的Awaiter的await_suspend和await_resume中加入日志记录协程的挂起和恢复点以及相关的线程ID、时间戳等信息这能帮助你清晰地追踪异步流程。7. 协程的适用场景与选择考量C20协程是一个强大的底层工具但并非所有场景都适用。非常适合的场景高性能网络服务器处理成千上万的并发连接用协程替代回调或状态机代码可读性极大提升。Nginx、Seastar等项目已广泛使用类似概念。游戏引擎游戏逻辑中充斥着大量的状态管理和异步操作如资源加载、动画播放、AI行为树协程可以将其编写为顺序代码。数据处理流水线多个处理阶段通过管道连接每个阶段可以用协程实现通过co_await等待上游数据处理后再co_yield给下游。生成器与惰性序列如前所述用于按需生成数据节省内存。需要谨慎评估的场景计算密集型任务协程的优势在于I/O等待而非并行计算。对于纯CPU计算使用std::thread或std::async可能更合适。极其简单的异步如果只有一个或少数几个简单的异步回调直接使用回调或std::future可能更轻量避免引入协程的复杂性和开销。对内存开销极其敏感每个协程帧都有开销通常至少几百字节。如果需要同时存在数百万个协程需要精心设计内存分配策略。选择线程还是协程线程由操作系统调度抢占式适用于利用多核CPU进行并行计算。上下文切换成本高涉及内核态创建数量受限于系统资源。协程由用户程序调度协作式适用于处理大量并发I/O。上下文切换成本极低只是用户态的函数调用可以轻松创建数十万甚至上百万个。它们不是互斥的可以结合使用使用线程池来处理CPU密集型任务而每个线程内使用协程来处理高并发的I/O。这正是很多现代异步框架如asio采用的模式。我个人在实际使用C20协程的过程中最大的体会是它极大地改善了异步代码的“心智模型”。你将异步逻辑从“回调地狱”的跳转中解放出来写成了从上到下的顺序语句调试时逻辑流也清晰得多。然而你必须对协程帧的生命周期、内存管理保持高度警惕并且需要一个设计良好的底层框架如自定义的Task、与执行器的集成来支撑上层应用。直接从语言原语开始写生产代码是非常困难的建议从成熟的协程库如cppcoro或asio的协程支持入手理解其设计再根据需要进行定制。这就像你不必从零开始写一个标准容器一样对于协程我们也应该优先考虑使用经过验证的库。