不能直接用 std::coroutine_handle 包装 curl 同步调用，因为 curl 默认阻塞式 I/O 会卡住线程、剥夺协程调度权；必须改用非阻塞的 curl_multi 接口并配合事件循环与自定义 awaiter 驱动。
为什么不能直接用 std::coroutine_handle 包装 curl 同步调用
因为 curl 默认是阻塞式 I/O，一旦在协程里调用 curl_easy_perform，整个线程就卡住，协程调度器失去控制权——这和“轻量级异步”目标完全背道而驰。C++20 协程本身不提供 I/O 能力，它只负责挂起/恢复执行流，底层必须配合非阻塞 socket 或事件循环。
常见错误现象：co_await 看似写了，但实际协程仍阻塞在系统调用上，CPU 占用低、吞吐无提升、并发数上不去。
- 必须使用
libcurl的 multi 接口（curl_multi_perform）或更底层的非阻塞 socket +poll/epoll -
libcurl需编译时启用ENABLE_THREADSAFE且禁用默认信号处理（CURLOPT_NOSIGNAL=1L） - 协程挂起点必须落在 I/O 就绪判断之后，比如等待
POLLIN或POLLOUT事件返回后才继续读写
如何用 std::suspend_always 和自定义 awaiter 驱动 curl_multi
核心思路是把 curl_multi 当作一个状态机驱动器：每次 co_await 对应一次 curl_multi_perform 调用，并根据返回的 CURLM_CALL_MULTI_PERFORM 或就绪 socket 列表决定是否挂起。
关键参数差异：CURLOPT_WRITEFUNCTION 和 CURLOPT_READFUNCTION 必须设为自定义回调，且返回值严格遵循 size * nmemb；否则 curl 会中止传输。
立即学习“C++免费学习笔记（深入）”；
- 自定义 awaiter 的
await_ready()应始终返回false（用std::suspend_always更清晰） -
await_suspend()中调用curl_multi_add_handle，并注册 socket 事件回调（CURLMOPT_SOCKETFUNCTION） - socket 回调里触发对应协程的
resume()，需用curl_multi_socket_action更新内部状态 - 避免在回调中直接操作协程栈，所有 resume 应通过线程安全队列或
std::atomic标记后由主循环统一处理
co_await http_get("https://api.example.com") 背后要补哪些基础设施
这个看似简洁的调用背后至少缺三块：HTTP 请求构建器、基于 curl_slist 的 header 管理、以及 response body 的零拷贝接收缓冲区（否则每次 realloc 都触发协程重入风险）。
性能影响点：如果对每个请求都新建 CURL* handle 并反复 curl_easy_init/curl_easy_cleanup，开销远超协程切换本身；应复用 handle + curl_easy_reset。
- 必须预分配
std::string缓冲区并传给CURLOPT_WRITEDATA，禁止用std::vector::push_back动态增长 - header 列表要用
curl_slist_append构建，且生命周期必须长于请求周期（建议用static const或std::shared_ptr管理） - 超时控制不能只靠
CURLOPT_TIMEOUT，需结合协程调度器的定时器（std::chrono::steady_clock+wait_until）做双重保障 - SSL 验证默认开启，内网调试时若跳过验证，务必显式设置
CURLOPT_SSL_VERIFYPEER和CURLOPT_SSL_VERIFYHOST为0L
为什么多数人卡在 curl_multi_fdset 和事件循环集成上
curl_multi_fdset 返回的 fd_set 是 libcurl 内部关心的 socket 集合，但它不保证跨平台一致：Windows 下不可用，Linux/macOS 下也仅反映当前就绪状态，不是长期监听句柄。直接把它喂给 select 容易漏事件或死锁。
容易踩的坑：curl_multi_fdset 每次调用前必须先 curl_multi_perform 一次，否则 fd_set 可能为空；且返回的 maxfd 值在多线程下可能失效。
- 推荐改用
CURLMOPT_SOCKETFUNCTION+CURLMOPT_TIMERFUNCTION，让 libcurl 主动通知你“该监听哪些 fd”和“下次要 wake up 的时间” - timer 回调里不要 sleep，而是用协程调度器的延迟唤醒机制（如
co_await delay_until(deadline)） - socket 回调收到
CURL_POLL_IN/CURL_POLL_OUT后，必须立刻调用curl_multi_socket_action，否则 libcurl 状态不同步 - 注意
curl_multi_info_read必须在每次curl_multi_socket_action后轮询，否则完成的请求永远不被感知
真正麻烦的从来不是协程语法，而是 libcurl 多路复用状态机与 C++20 协程生命周期的对齐——比如一个 handle 在 resume 途中被 cancel，它的 socket 回调可能还在运行，此时 curl_multi_remove_handle 必须同步等待回调退出，否则内存就悬空了。
