协程入口必须用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 << resp.body << "\n";
}, boost::asio::detached);
ctx.run();
}
注意：Boost.Asio 的 co_spawn 是目前最稳妥的协程调度入口，别试图手动 resume handle —— 容易漏掉调度器绑定和异常传播路径。
http_get 必须包装底层 socket 操作为可挂起对象
裸写 boost::beast::http::async_read 或 async_connect 不会自动变成协程友好接口；必须把每个异步操作封装成返回 awaitable 的函数，并在内部使用 boost::asio::use_awaitable 作为完成令牌。
立即学习“C++免费学习笔记（深入）”；
关键点：
-
async_connect、async_write、async_read都要传boost::asio::use_awaitable，不是std::bind或 lambda - 每个 awaitable 操作之间不能共享同一
tcp::socket实例而不重置状态 —— 否则第二次co_await可能立即完成或崩溃 - DNS 解析也要协程化：
co_await resolver.async_resolve(host, "80", boost::asio::use_awaitable)
示例片段（简化）：
boost::asio::awaitable<std::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;
}
HTTP 响应体读取必须分块 await，否则可能阻塞或截断
Beast 的 http::response_parser<http::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<std::string, std::string> 或类似机制显式返回。
