协程真正挂起需满足：await_ready()返回false、await_suspend()注册协程句柄到事件循环且socket设为非阻塞、await_resume()安全恢复；HTTP请求体须用shared_ptr等延长生命周期；响应应封装为结构化HttpResponse；超时需协程自主驱动，TLS调用须处理SSL_WANT_READ分支。
协程函数怎么写才能真正挂起而不阻塞线程
直接用 co_await 等待一个未就绪的 socket 操作，但底层没做非阻塞 + 事件循环注册，协程会假挂起——实际还是同步等待，甚至卡死。关键不是语法对不对，而是 awaiter 的 await_ready()、await_suspend()、await_resume() 三者是否协同工作。
-
await_ready()必须返回false（除非数据已就绪），否则协程根本不会挂起 -
await_suspend()里必须把当前协程句柄（handle）注册到 epoll/kqueue/IOCP 的等待队列，并触发一次事件循环轮询；不能只存起来不调度 - socket 必须提前设为
O_NONBLOCK（Linux）或WSAEventSelect（Windows），否则recv()/send()仍会阻塞线程
HTTP请求体如何在协程栈上安全构造和传递
协程挂起后栈帧可能被销毁，所有局部变量（包括 std::string 请求头、body）必须确保生命周期覆盖整个异步流程。堆分配不是唯一解，但需明确所有权边界。
- 不要把
std::string成员直接传给co_await http_get("https://...")——调用完协程挂起，该字符串可能已被析构 - 推荐用
std::shared_ptr包裹请求上下文（含 URL、headers、body），并在 awaiter 中持有该指针，直到响应完成 - 若用
std::coroutine_handle手动管理，需在await_suspend()返回前确保上下文对象地址稳定（例如分配在堆上或 static storage）
如何让 co_await http_get() 返回结构化响应而不是裸字节
裸 std::string 响应体容易引发二次解析错误，且无法携带状态码、header 等元信息。协程的返回值类型必须承载完整 HTTP 响应语义。
- 定义
struct HttpResponse { int status_code; std::unordered_map<:string std::string> headers; std::string body; };</:string> - 协程函数签名应为
Task<httpresponse> http_get(std::string url)</httpresponse>，其中Task是自定义协程 Promise 类型，其get_return_object()返回可co_await的 handle，return_value()存储HttpResponse - 注意：不能在
await_resume()中 new 一个临时HttpResponse返回——它会被移动构造进协程 promise 的存储区，但若移动构造函数抛异常，协程将崩溃
为什么 epoll + 协程组合下仍会出现连接超时或重试失效
协程不等于自动超时控制。epoll_wait() 只告诉你 fd 就绪，但不告诉你“这个连接是不是卡在三次握手”或者“TLS 握手花了 15 秒”。超时必须由协程自身驱动，而非依赖系统事件。
立即学习“C++免费学习笔记（深入）”；
- 单独启一个定时器协程（如
co_await sleep_for(5s)）并和主请求协程通过std::stop_token或原子 flag 协同，是目前最可控的方式 - 不要复用同一个 socket fd 多次发起不同请求——HTTP/1.1 keep-alive 下，需解析响应 boundary 并清空缓冲区，否则下次
co_await recv()会读到上一次残留数据 - SSL/TLS 层（如 OpenSSL 的
SSL_read）同样要适配协程：它可能返回SSL_WANT_READ，此时需挂起并等 epoll 触发可读事件，而不是直接重试
真正的难点不在协程语法，而在每个系统调用返回值含义与事件循环状态的精确映射——少一个 if (ret == SSL_WANT_READ) 分支，整个请求链就静默失败。
