C++如何实现基于C++20协程的轻量级异步HTTP请求-C++-PHP中文网

协程http客户端需基于boost::beast实现，返回boost::asio::awaitable类型，重载operator co_await以支持异步i/o；必须使用beast::http::parser解析响应，配合zlib处理gzip，并显式检查error_code与http状态码，超时由socket设置，dns解析须异步化。

c++如何实现基于c++20协程的轻量级异步http请求

协程函数必须返回 `task` 或类似可等待类型

直接用 co_await 发起 HTTP 请求的前提是：被 await 的对象得满足 *awaitable* 协议。标准库没提供 HTTP 客户端，所以你不能写 co_await http_get("https://api.example.com") 就完事——这会编译失败，因为返回类型不是可等待的。

实际做法是封装一个自定义类型（比如 http_request），重载 operator co_await，内部触发非阻塞 socket 操作，并在 I/O 完成时唤醒协程。主流方案如 libcurl + curl_easy_setopt(..., CURLOPT_XFERINFOFUNCTION, ...) 配合事件循环；更轻量的选型是 boost::asio 的 async_connect / async_read，再包装成 awaitable。

别试图把同步 curl_easy_perform 直接塞进协程里——它会阻塞整个线程，失去异步意义
std::coroutine_handle 本身不调度，你得自己配事件循环（比如 boost::asio::io_context::run()）
返回类型推荐用 boost::asio::awaitable<:string></:string> 而非裸 task<:string></:string>，避免重复造轮子

HTTP 解析不能靠 `std::string::find` 硬拆包

协程暂停点通常设在读取响应头或响应体时，但 HTTP 协议有分块传输、gzip 压缩、连接复用等特性。如果只等固定字节数或简单扫描 "\r\n\r\n"，大概率在 chunked 编码或压缩响应里出错——要么提前结束，要么卡死。

真正可行的是复用成熟解析器，比如 http_parser（C 实现，零依赖）或 boost::beast::http::parser。后者与 boost::asio 协程天然契合，parser::get().body().data() 可直接绑定到协程的缓冲区。

boost::beast::http::request<:beast::http::string_body></:beast::http::string_body> 和 response<:beast::http::dynamic_body></:beast::http::dynamic_body> 是常用组合
别在协程里手动管理 Content-Length 计数——解析器已处理好边界，你只需 co_await parser.async_wait(...)
gzip 响应要额外启用 boost::beast::zlib::flate_stream，否则 parser 会把压缩流当纯文本解析

`co_await` 后的异常必须显式捕获

HTTP 请求失败不会自动 throw 异常，而是通过 boost::system::error_code 返回。如果你写 auto resp = co_await http_get(...); 却没检查 resp.result() 或 ec，程序可能静默返回空字符串或崩溃（比如访问 parser.body().data() 前未验证解析状态）。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

正确模式是：所有 co_await 调用后立即检查错误，且把网络层错误映射为业务可识别的枚举（如 http_error::connection_refused），而不是裸抛 std::system_error。

co_await 本身不传播异常，但 await_resume() 里若 throw，协程会终止并沿调用栈冒泡
超时必须由底层 socket 设置（如 socket.expires_after(30s)），协程内无法靠 std::this_thread::sleep_for 实现
重试逻辑要放在协程外（比如 while 循环套协程调用），否则每次重试都新建协程帧，开销不可控

多个并发请求别直接 `co_await` 串行写

写成 co_await req1(); co_await req2(); co_await req3(); 是顺序执行，耗时是三者之和。真要并发，得用 boost::asio::when_all 或手写 std::vector<awaitable>></awaitable> 收集后 co_await when_all(...)。

注意：并发数不是越多越好。操作系统对 socket 数量有限制（ulimit -n），boost::asio::io_context 默认单线程，高并发下需配合 thread_pool 或 strand 避免数据竞争。

when_all 返回的是 std::tuple，不是 std::vector，解包得用结构化绑定或 std::get(result)
每个请求应独占 socket，复用连接需用 keep-alive + 连接池，否则频繁建连反而更慢
协程栈默认很小（几十 KB），大量并发请求易触发栈溢出，建议用 boost::asio::experimental::make_parallel_group 控制并发度

最麻烦的其实是 DNS 解析——boost::asio::ip::tcp::resolver::async_resolve 也得协程化，且系统 getaddrinfo 可能阻塞，生产环境务必替换为异步 DNS 库（如 c-ares）。这点容易被忽略，一查域名就卡住整个协程调度器。