协程入口函数必须用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<t></t>等可等待类型），且被事件循环实际调度 - 不要在非协程函数里试图“同步等待”协程结果（如用
.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(...)），就失去了协程的可控挂起能力，也无法处理重定向、超时、部分失败等中间状态。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实际应拆成多个细粒度 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<char></char>+data()，且 vector 必须是协程帧成员或堆分配 - 协程函数返回后，其帧内存会被回收，所以不要返回指向协程局部变量的引用或指针
轻量级不等于无脑轻——每个 awaitable 的资源归属、错误传播路径、取消语义都得手工厘清。稍不注意，协程就变成更难 debug 的隐式状态机。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
