boost.asio协程需c++20及特定编译选项（如-std=c++20、-fcoroutines、dboost_asio_has_co_await），仅boost 1.75+支持；awaitable必须由io_context.run()驱动，不可直接调用；socket操作须用use_awaitable令牌，且注意头文件、上下文绑定与缓冲区类型。
Boost.Asio协程需要C++20且启用特定编译选项
Boost.Asio的co_await支持不是开箱即用的——它依赖编译器对C++20协程的完整实现，且必须显式启用。GCC 10+、Clang 13+ 和 MSVC 19.30+ 才具备基本可用性，但即使满足版本要求，漏掉编译开关也会直接报错‘co_await’ is not a keyword或no matching function for operator co_await。
关键编译参数必须包含：
-
-std=c++20（不能是c++2b或gnu++20，部分Boost版本对标准名敏感） -
-fcoroutines（GCC/Clang）或/EHsc /std:c++20 /await（MSVC） -
-DBOOST_ASIO_HAS_CO_AWAIT（必须定义，否则boost::asio::awaitable不会暴露协程接口）
另外，Boost 1.75+ 才正式支持协程；低于此版本即使加了宏也无效。
awaitable类型不能直接return，必须由io_context.run()驱动
写完一个返回boost::asio::awaitable<int></int>的函数，直接调用它只会得到一个未启动的协程对象，不会执行任何异步逻辑。常见错误是把它当普通函数用：auto res = my_handler();——这行代码不触发网络IO，也不抛异常，只是构造了一个awaitable实例。
真正运行协程需通过boost::asio::io_context调度：
boost::asio::io_context ioc;
boost::asio::co_spawn(ioc, my_handler(), [](std::exception_ptr e) {
if (e) std::rethrow_exception(e);
});
ioc.run();
注意两点：
-
co_spawn第一个参数必须是活跃的io_context，传临时对象或已stopped()的上下文会导致静默失败 - 协程内部若抛出异常，不会传播到
co_spawn外层，必须靠回调参数std::exception_ptr捕获并处理 - 不要在协程里调用
io_context::run()——这会阻塞当前线程，破坏协程调度语义
socket操作必须用async_*成员函数，不能混用传统回调风格
Boost.Asio协程模式下，所有异步操作必须返回可等待对象（如socket.async_read_some(...)返回awaitable），但默认的basic_stream_socket成员函数并不直接支持——它们只提供基于回调的async_*重载，而没有co_await友好的版本。
正确做法是使用boost::asio::use_awaitable作为完成令牌：
boost::asio::ip::tcp::socket sock(ioc); // ❌ 错误：没有 async_read_some(use_awaitable) 重载 // sock.async_read_some(buffer, some_handler); // ✅ 正确：显式传入 use_awaitable auto n = co_await sock.async_read_some(buffer, boost::asio::use_awaitable);
容易忽略的细节：
- 必须包含
<boost></boost>头文件，否则use_awaitable不可见 - socket必须绑定到某个
io_context（构造时传入），否则co_await会立即抛boost::system::system_error（error_code = operation_not_supported） - 缓冲区
buffer必须是boost::asio::mutable_buffer或boost::asio::const_buffer类型，不能传裸指针或std::vector::data()而不配长度
协程栈与异常传播比想象中更脆弱
Boost.Asio协程底层复用线程栈，不提供独立协程栈（不像libco或Boost.Coroutine2），这意味着栈溢出风险真实存在——递归调用协程、或在协程内分配大数组，都可能直接导致段错误，且无明确错误提示。
异常传播路径也受限：从协程内抛出的异常，只能被co_spawn的完成处理器捕获；如果协程嵌套多层（A co_await B，B co_await C），C中抛异常会逐层向上“冒泡”，但一旦某层用了try/catch吞掉，上层就收不到——这和同步代码直觉不同。
调试建议：
- 用
BOOST_ASIO_ENABLE_HANDLER_TRACKING宏开启跟踪，日志会显示每个co_await点的挂起/恢复位置 - 避免在协程中做耗时同步计算；CPU密集型任务应切到
post(ioc, []{...})或专用线程池 - 连接超时等场景别依赖
std::this_thread::sleep_for，改用boost::asio::steady_timer+async_wait+co_await
协程的可读性优势明显，但它的执行模型紧耦合于io_context生命周期和编译器协程实现细节，稍有不慎就会退化成难以调试的静默失败。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
