C++20协程需配合异步I/O框架（如boost::asio）才能真正异步，裸用std::coroutine会因阻塞I/O卡死；必须用async_read/write、绑定io_context、显式错误处理，避免协程静默失败。
协程不是万能的，C++20 std::coroutine 本身不提供调度器
直接用 co_await 写下载逻辑，代码看似异步，实际可能卡死在阻塞 I/O 上。C++ 标准库没给网络、文件等异步原语，std::coroutine 只是语法糖，底层还得靠第三方事件循环（比如 libuv、asio）或自己实现调度。很多人写了半天 co_await http_get(...)，结果发现还是单线程阻塞——因为没把 socket 设成非阻塞，也没挂到 epoll/kqueue 上。
实操建议：
- 别自己从零写调度器；优先用
boost::asio（支持 C++20 协程）或libuv+ 封装协程适配层 - 确保所有 I/O 操作都走异步路径：
async_read/async_write，而非read/write - 每个协程必须绑定到一个事件循环线程，跨线程 resume 需手动处理同步（比如用
post转发）
boost::asio::awaitable 是目前最稳的生产级选择
相比裸用 std::coroutine，boost::asio::awaitable 已封装好调度、内存管理、异常传播和线程安全 resume。它默认运行在 io_context 上，天然适配异步 socket、timer、resolver 等组件。
常见错误现象：协程启动后没调 io_context::run()，或者只 run 一次就退出，导致后续 co_await 永远不唤醒。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 用
co_spawn(io_ctx, your_awaitable_func(), asio::detached)启动协程，别手动co_await到顶层 - HTTP DNS 解析必须用
asio::ip::tcp::resolver::async_resolve，不能用getaddrinfo - 连接超时要用
asio::steady_timer+co_await timer.async_wait()配合socket.cancel()，别依赖 socket 选项
并发数不是越大越好，epoll 和内存分配会成为瓶颈
开 10 万个协程不等于有 10 万个并发连接。Linux 默认 epoll 限制、文件描述符上限、堆内存碎片、以及 asio::awaitable 每个实例约 200–400 字节的栈帧开销，都会让吞吐在某个阈值后急剧下降。
性能影响明显的表现：RSS 内存飙升但 QPS 不涨，strace -e epoll_wait 显示频繁唤醒但无事件，或 perf record -e syscalls:sys_enter_accept 发现 accept 延迟变高。
实操建议：
- 用
ulimit -n和/proc/sys/fs/file-max提前调高限制，但别盲目设到百万级 - 协程里避免大对象拷贝；用
std::string_view处理响应体，流式解析 JSON 或 HTML - 连接池比无限新建 socket 更有效；对同一 host 复用
tcp::socket实例（HTTP/1.1 keep-alive）
错误处理必须显式覆盖 std::system_error 和 HTTP 状态码
协程里抛异常不会自动终止整个爬虫流程，co_await 失败后若没 catch，会静默销毁协程——你看到的现象可能是“某些 URL 没日志、没重试、也不报错”。更麻烦的是，网络错误（如 asio::error::operation_aborted）和业务错误（如 429 Too Many Requests）混在一起，统一用 try/catch 很难区分。
实操建议：
- 每个
co_await调用后检查ec（error_code），别依赖异常路径 - HTTP 响应头必须解析
Status行，4xx/5xx 视为失败，但 301/302 要按需跟随（注意跳转深度限制） - 重试逻辑不要写在协程内部；用外部控制器统一管理退避策略（如 exponential backoff），避免协程堆栈爆炸
协程真正难的不是怎么写 co_await，而是怎么让十万次 co_await 都落在正确的线程、正确的 socket、正确的错误分支里——漏掉一个 ec 检查，或少设一个 SO_RCVBUF，整批请求就可能集体卡住几秒。
