C++如何实现基于协程化的轻量级异步HTTP-GET网络请求逻辑

C++20 协程让异步编程变得更优雅，但真正上手写一个轻量级 HTTP GET 请求时，很多人会发现：这个东西远没想象中那么简单。稍不留神，协程就变成了一个隐藏的状态机，调试起来比回调更痛苦。那么，一个基于协程的异步 HTTP GET 到底该怎么落地？下面拆开揉碎了讲。

协程入口函数必须用co_await启动，不能直接调用；HTTP GET需拆分为DNS解析、TCP连接、请求发送、响应读取等细粒度awaitable步骤，并确保资源生命周期安全。

协程入口函数必须用 co_await 启动，不能直接调用

很多刚接触 C++20 协程的人，会把异步 HTTP GET 写成普通函数调用形式，比如 http_get("https://example.com")，结果发现程序立刻返回、根本不等待响应。原因很直接：协程函数（返回 std::future 或自定义 awaitable 类型）本身不执行任何操作，它只构造一个挂起对象；必须用 co_await 触发调度和恢复，才能真正跑起来。

正确的做法是：整个请求逻辑必须包裹在另一个协程函数中，并且该函数本身需要被调度器驱动——比如通过 std::thread + executor.run()，或集成到 boost::asio::io_context 中。裸调用 http_get 只是生成一个未启动的 awaitable，根本不会发起网络连接。

• 确保顶层协程函数标记为 async（或返回 task 等可等待类型），并且被事件循环实际调度。
• 不要在非协程函数里试图“同步等待”协程结果（比如用 .get()），这会导致线程阻塞，失去轻量优势。
• 若使用 boost::asio，务必调用 co_spawn(io_ctx, http_get(...), detach) 或类似机制启动。

HTTP GET 协程需封装底层 socket 操作为 awaitable，不能依赖 blocking socket

标准 socket + connect + send + recv 是阻塞式的，直接放进协程会卡住整个线程。必须把每个 I/O 步骤转为非阻塞 + async_wait 或 async_read_some 的 awaitable 封装。

以 boost::asio 为例，tcp::socket::async_connect 返回的是可等待对象，但需要配合 use_awaitable；而原生 Linux epoll 或 Windows IOCP 则需手动包装 await_suspend 和 await_resume。

• DNS 解析也得异步：用 asio::ip::tcp::resolver::async_resolve，而非 getaddrinfo。
• HTTP 头解析不能用 std::getline 这类同步读取，应基于 asio::streambuf + async_read_until。
• 响应体读取建议分块（chunked）或按 Content-Length 预分配，避免一次性 async_read 超长数据导致协程长时间挂起。

co_await 在 HTTP 流程中要分阶段挂起，不是“一 await 到底”

一个完整 HTTP GET 至少包含：DNS 查询 → TCP 连接 → 发送请求头 → 等待响应头 → 读取响应体。如果把整段逻辑写在一个 co_await 表达式里（比如幻想有个 co_await full_http_get(...)），就失去了协程的可控挂起能力，也无法处理重定向、超时、部分失败等中间状态。

实际应拆成多个细粒度 awaitable：比如 co_await resolve_host(host)、co_await connect_socket(sock, ep)、co_await write_request(sock, req)、co_await read_status_line(buf) 等。每个步骤失败可以单独处理，超时也可按阶段设置（如 DNS 2s、连接 5s、首行响应 10s）。

• 每个 awaitable 应有自己的错误码返回路径，避免用异常传播——协程异常开销大且难以跨栈捕获。
• 重定向需显式判断 3xx 状态码后，重新构造 URL 并递归/循环发起新协程，不能靠“自动跳转”隐藏逻辑。
• 超时控制推荐用 asio::steady_timer + co_await timer.async_wait(use_awaitable) 包裹关键步骤。

协程栈与内存生命周期容易出错，尤其在回调上下文中

协程挂起时，局部变量（包括 std::string、std::vector、甚至 tcp::socket 对象）默认存于协程帧（coroutine frame）中，由编译器管理。但一旦你把某个对象（比如 socket）移出协程帧、传给外部回调（如 async_read 的 lambda），而该回调又在协程恢复前触发，就会访问已销毁的内存。

典型错误：在协程里创建 tcp::socket sock(io_ctx)，然后调用 sock.async_read_some(..., [&](error_code ec, size_t n) { ... }) —— 这个 lambda 捕获了协程局部变量，但协程可能已销毁，lambda 执行时访问野指针。

• 所有传递给底层异步操作的缓冲区、socket、resolver 必须保证生命周期覆盖整个异步过程，推荐用 shared_ptr 或 move 到 awaitable 内部持有。
• 避免在协程中用栈上 std::array 作 recv 缓冲区并传给 async_read；改用 std::vector + data()，且 vector 必须是协程帧成员或堆分配。
• 协程函数返回后，其帧内存会被回收，所以不要返回指向协程局部变量的引用或指针。

轻量级不等于无脑轻——每个 awaitable 的资源归属、错误传播路径、取消语义都得手工厘清。稍不注意，协程就变成更难 debug 的隐式状态机。