协程入口必须用co_await驱动，http_get等函数仅构造awaitable对象而不执行；需用co_spawn调度、use_awaitable封装异步操作、分块读取响应体、妥善管理资源生命周期与异常传播。
协程入口函数必须用 co_await 驱动，不能直接调用
协程函数（如返回 std::future 或自定义 awaitable 类型的 http_get）本身不执行，只构造 suspend point。常见错误是像普通函数一样调用：http_get("https://api.example.com") —— 这只会返回一个未启动的 awaitable 对象，HTTP 请求根本不会发出去。
正确做法是：在支持协程的上下文中（如 main() 声明为 co_await-friendly，或封装进 std::jthread + std::coroutine_handle）显式 co_await 它：
auto main() -> int {
static std::io_context ctx;
static std::signal_set sig{ctx, SIGINT};
boost::asio::co_spawn(ctx, []() -> boost::asio::awaitable<void> {
auto resp = co_await http_get("https://httpbin.org/get");
std::cout
<p>注意：Boost.Asio 的 <code>co_spawn</code> 是目前最稳妥的协程调度入口，别试图手动 resume handle —— 容易漏掉调度器绑定和异常传播路径。</p>
<h3>
<code>http_get</code> 必须包装底层 socket 操作为可挂起对象</h3>
<p>裸写 <code>boost::beast::http::async_read</code> 或 <code>async_connect</code> 不会自动变成协程友好接口；必须把每个异步操作封装成返回 <code>awaitable</code> 的函数，并在内部使用 <code>boost::asio::use_awaitable</code> 作为完成令牌。</p>
<p>关键点：</p>
<ul>
<li>
<code>async_connect</code>、<code>async_write</code>、<code>async_read</code> 都要传 <code>boost::asio::use_awaitable</code>，不是 <code>std::bind</code> 或 lambda</li>
<li>每个 awaitable 操作之间不能共享同一 <code>tcp::socket</code> 实例而不重置状态 —— 否则第二次 <code>co_await</code> 可能立即完成或崩溃</li>
<li>DNS 解析也要协程化：<code>co_await resolver.async_resolve(host, "80", boost::asio::use_awaitable)</code>
</li>
</ul>
<p>示例片段（简化）：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<pre class="brush:php;toolbar:false;">boost::asio::awaitable<:string> http_get(std::string_view url) {
auto executor = co_await boost::asio::this_coro::executor;
tcp::resolver resolver{executor};
auto eps = co_await resolver.async_resolve("httpbin.org", "80", boost::asio::use_awaitable);
tcp::socket sock{executor};
co_await boost::asio::async_connect(sock, eps, boost::asio::use_awaitable);
// ... 构造请求、发送、读响应
co_return body;
}</:string>
HTTP 响应体读取必须分块 await，否则可能阻塞或截断
Beast 的 http::response_parser<:string_body></:string_body> 默认不支持一次性读完大响应体。如果直接 co_await http::async_read(sock, buffer, parser, use_awaitable)，它只保证读到 headers 和第一个 chunk，后续 body 可能未收全。
安全做法是循环等待 parser 完成：
- 先
co_await http::async_read_header获取 status 和 headers - 再根据
parser.get().need_eof()和parser.is_done()判断是否需继续读 - 对 streaming body，用
http::async_read循环直到parser.is_done() == true
漏掉这一步，parser.get().body() 可能为空或只有前几百字节 —— 尤其当服务端用 chunked encoding 或返回大 JSON 时。
协程栈与异常传播容易被忽略
Boost.Asio 协程默认在栈上分配 suspend state，但若 http_get 中局部变量持有 socket、buffer 等资源，协程挂起后这些对象生命周期必须延续到恢复执行 —— 所以推荐把关键资源（如 tcp::socket、flat_buffer）声明为协程函数内的 auto 变量，而非捕获到 lambda 里。
异常处理也不同：协程内抛异常不会自动传播到调用侧，除非你用 co_spawn 的 detached 以外策略（如 as_tuple），或手动 catch 后 co_yield 错误值。
最常踩的坑是：在协程里 throw std::runtime_error("timeout")，结果主线程毫无感知 —— 因为异常被协程框架吞掉了。真要暴露错误，得用 std::expected<:string std::string></:string> 或类似机制显式返回。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
