不能直接用 std::jthread + std::promise 模拟协程风格，因为 c++20 协程本身不提供 i/o 调度能力，仅生成状态机；真正的异步 http 必须依赖非阻塞 socket 与事件循环，否则 co_await 仍是同步阻塞。
为什么不能直接用 std::jthread + std::promise 模拟“协程风格”
很多人想绕过第三方库，用 C++20 协程语法糖包装 std::thread 或 std::jthread，结果发现根本不是异步——co_await 会阻塞线程，且无法挂起系统 I/O。C++20 协程本身不提供任何 I/O 调度能力，它只负责生成可挂起/恢复的状态机。真正的异步 HTTP 必须依赖底层非阻塞 socket 和事件循环（比如 libcurl 的 multi interface、asio 的 async_read、或 OS 原生 io_uring/epoll/kqueue）。
所以：没有运行时调度器，co_await 就只是个语法摆设；没集成非阻塞网络栈，所谓“协程 HTTP”实际仍是同步阻塞调用。
用 boost::asio + awaitable 是目前最稳妥的落地路径
Boost.Asio 自 1.70 起支持原生协程，封装了 epoll/kqueue/iocp，并提供 boost::asio::awaitable<t></t> 类型和 co_await 友好接口。它不是“胶水层”，而是真正把协程与异步 I/O 绑定在一起的运行时。
-
boost::asio::ip::tcp::resolver解析域名，co_await不阻塞线程 -
boost::asio::ip::tcp::socket::async_connect被封装为awaitable，挂起直到连接建立或超时 - HTTP 请求头手动构造（GET /path HTTP/1.1），用
async_write发送，async_read接收响应 - 整个链路可写成线性逻辑，但底层全是非阻塞调用 + 事件循环驱动
示例片段（省略错误检查）：
boost::asio::awaitable<:string> http_get(boost::asio::io_context& ctx, std::string host, std::string path) {
auto executor = co_await boost::asio::this_coro::executor;
boost::asio::ip::tcp::resolver resolver(executor);
auto endpoints = co_await resolver.async_resolve(host, "80", boost::asio::use_awaitable);
boost::asio::ip::tcp::socket socket(executor);
co_await socket.async_connect(endpoints.begin()->endpoint(), boost::asio::use_awaitable);
std::string req = "GET " + path + " HTTP/1.1\r\nHost: " + host + "\r\nConnection: close\r\n\r\n";
co_await boost::asio::async_write(socket, boost::asio::buffer(req), boost::asio::use_awaitable);
std::array<char> buf;
auto [ec, n] = co_await socket.async_read_some(boost::asio::buffer(buf), boost::asio::use_awaitable);
co_return std::string(buf.data(), n);
}</char></:string>
libcurl + CURLM_MULTI_SOCKET + 协程封装是更轻量的选择
如果你不想引入 Boost，libcurl 的 multi interface 支持事件驱动模式，配合自定义 awaiter 可桥接协程。关键不是调 curl_easy_perform（那是同步），而是用 curl_multi_socket_action 驱动内部 fd 监听，并在 socket 可读/可写时 resume 协程。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 需自己实现一个
curl_awaiter，内部监听CURLM_CALL_MULTI_PERFORM和 socket 事件 - 每次
co_await curl_awaiter{easy_handle}时，把当前协程 handle 存入 curl 的 userptr，等事件触发再 resume - 必须调用
curl_multi_setopt(..., CURLMOPT_SOCKETFUNCTION, ...)注册 socket 回调，否则 libcurl 不通知你 fd 状态变化 - 容易漏掉
CURLMSG_DONE处理，导致响应体没被完整读取就结束协程
这种方案代码量不小，但二进制依赖只有 libcurl，适合嵌入式或受限环境。
别碰 std::generator 或 std::task 这类实验性提案
截至 C++23，std::generator 是只读迭代器，不能用于 I/O 等待；std::task 仍未标准化，各编译器无一致实现。网上有些基于 std::coroutine_handle 手搓调度器的 demo，往往只模拟“延迟等待”，没对接真实 socket，跑通了也发不出 HTTP 请求。
真正上线项目里，协程的价值在于降低回调地狱的维护成本，不是为了炫技。选 Boost.Asio 或 libcurl multi，不是因为它们“支持协程”，而是因为它们有经过验证的异步 I/O 实现——协程只是让调用方式变干净了而已。
最常被忽略的一点：HTTP GET 的“简单”只存在于请求行，但处理重定向、chunked 编码、keep-alive、TLS、DNS 缓存这些，全都要额外逻辑。协程不会帮你自动处理它们，该写的 parser 和状态机一个都不能少。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
