协程挂起必须对接异步i/o机制（如epoll/iocp），禁用阻塞调用；resume时须检查socket状态与errno；断点续传需外部持久化offset/etag；取消时需安全析构并管理socket生命周期。
协程挂起前必须确保网络句柄可异步等待
直接用 std::this_thread::sleep_for 或阻塞式 recv 挂起协程，会导致整个线程卡死，协程调度器失去控制权。C++20 协程本身不提供 I/O 调度能力，挂起点必须对接真正的异步 I/O 机制（如 epoll、IOCP 或 libuv）。
常见错误现象：co_await 后协程没恢复，下载卡住，CPU 占用却很低——本质是挂起点没被事件循环唤醒。
- Linux 下优先用
epoll+readv非阻塞 socket，把 socket 设为O_NONBLOCK，并在EPOLLIN就绪时 resume 协程 - Windows 下需绑定到
IOCP，不能依赖WSAEventSelect，后者无法与协程 promise 的 await_suspend 无缝衔接 - 别用
std::jthread或普通线程池模拟“异步”，那只是多线程阻塞，不是协程挂起
resume 时要检查 socket 状态和 errno
网络中断、对端关闭、超时重试等场景下，recv 可能返回 -1 并设置 errno（如 EAGAIN、ECONNRESET、ETIMEDOUT）。协程 resume 后若忽略这些，会误判为“数据已就绪”，导致读取乱码或崩溃。
使用场景：断点续传中，HTTP Range 请求返回 206 Partial Content 后，后续 chunk 传输中途断开，必须识别并重连，而非继续 co_await 原 socket。
立即学习“C++免费学习笔记（深入）”；
-
recv返回值为 0 表示对端正常关闭，应终止下载并触发完成回调 - 返回 -1 且
errno == EAGAIN || errno == EWOULDBLOCK才该再次挂起，等待下一次就绪 - 其他
errno（如ECONNABORTED）需立即清理资源、记录错误，并抛出异常或通过co_return传递失败状态
断点续传需在协程外部持久化 offset 和 etag
协程栈是临时的，一旦被销毁（如异常退出、任务取消），所有局部变量（包括已下载字节数）丢失。下次重启下载时，若只靠内存里的 offset，就会从头开始。
参数差异：HTTP Range: bytes=1024- 依赖服务端支持；若服务端不认 Range（返回 200 而非 206），必须主动 abort 并报错，不能硬吞全部响应体。
- 每次写入磁盘后，立刻用原子操作或轻量级文件（如
.download.state）更新当前offset和响应头中的ETag - 启动时先读取 state 文件，构造带
Range和If-Range头的请求，避免服务端忽略断点 - 不要在协程内部用
std::ofstream直接追加写——文件系统调用可能阻塞，应交由独立 I/O 线程处理，协程只发指令
取消下载时协程必须能安全析构
用户点击“取消”，主线程调用 cancel()，但此时协程可能正卡在 await_suspend 中等待 epoll 事件。如果 promise 对象被提前 delete，resume 时访问已释放内存，必然 crash。
性能 / 兼容性影响：GCC 12+ 对协程取消支持较稳；Clang 14 之前有 promise 析构顺序 bug，取消期间访问 coroutine_handle 易段错误。
- 在 promise_type 中实现
unhandled_exception()，捕获取消引发的std::stop_exception，并标记m_cancelled = true - 每次
await_ready()前检查m_cancelled，为 true 则直接返回 false，让await_suspend不执行 - socket 关闭必须用
shutdown(SHUT_RDWR)+close()组合，不能只 close——否则 epoll 可能仍上报就绪事件，触发已销毁协程的 resume
最易被忽略的是：协程暂停时，socket 的生命周期必须独立于协程对象。哪怕协程函数退出了，只要还有未完成的系统调用（比如正在 kernel 中排队的 epoll_wait），socket 就不能 close。得靠引用计数或 RAII 容器来管理。
