做不到真正轻量且不依赖第三方库的协程异步HTTP请求，因C++20标准库无网络I/O awaitable封装，std::coroutine仅为语法协议；libcurl阻塞调用会卡死事件循环，io_uring虽近零依赖但仍需liburing头文件和内核支持，DNS解析亦无法纯异步绕过。
做不到真正轻量且不依赖第三方库的协程异步 HTTP 请求——C++20 标准库本身不提供任何网络 I/O 的 awaitable 封装，std::coroutine 只是语法协议，没有 socket、DNS、TLS 或事件循环。
为什么 std::coroutine + libcurl 会卡死
常见错误是把 curl_easy_perform 直接 co_await：它本质是阻塞调用，挂起协程后线程仍在等系统调用返回，整个 event loop 停摆。libcurl 的 multi interface 虽支持轮询，但需手动管理 fd 集合、超时、状态迁移，并自己实现 await_suspend 唤醒逻辑——这已不是“不依赖第三方”，而是重写半个网络栈。
-
curl_multi_fdset+select轮询必须在单独线程或主循环中持续驱动，协程无法自动感知 fd 就绪 - 每次
co_await需绑定到具体 fd 和事件类型（读/写/错误），而 libcurl 不暴露底层 socket 生命周期控制权 - HTTPS 场景下还需处理 OpenSSL 的非阻塞 BIO 唤醒，复杂度指数级上升
io_uring 是唯一可行的“近零依赖”路径
Linux 5.11+ 内核提供 io_uring，可直接提交 read/write/connect 等异步请求并等待完成，无需用户态事件循环。但它不是“无依赖”：你仍需 liburing 头文件（仅头文件，不需链接库）和内核支持，且必须手动管理 buffer 生命周期与 sqe/cqe 交互。
-
io_uring_setup和io_uring_enter需在初始化阶段调用一次，后续所有操作基于 ring 共享内存 - 每个 awaiter 实例（如
io_uring_awaiter）必须持有io_uring*指针和唯一user_data标识 - DNS 解析仍需
getaddrinfo_a或自己开线程做同步解析——这是最大缺口，无法纯异步绕过
Boost.Asio 为何仍是事实标准
不是因为它“重”，而是它把所有不可回避的复杂性封装成了可组合的 awaitable 原语：async_connect、async_read、async_write 全部自动适配底层 epoll/kqueue/io_uring，并统一调度到 io_context。所谓“轻量”，是指你不用写调度器、不用管 fd 管理、不用手写状态机——这些工作已被验证十年以上。
立即学习“C++免费学习笔记（深入）”；
- 编译时启用
-DBOOST_ASIO_SEPARATE_COMPILATION可减少模板膨胀 - 只链接
-lboost_system（HTTP 不需 SSL 时）即可运行 -
boost::beast::http::request和response类型安全，避免手动拼接 header 和解析 chunked
真正的轻量不在“删掉多少代码”，而在“屏蔽多少系统细节”。试图绕过 Boost.Asio 或 liburing 去手搓，只会把精力耗在 fd 泄漏、buffer overrun、DNS 超时竞态这些边缘 case 上——而这些正是成熟库早已解决的问题。
