C++20协程本身不提供异步I/O能力，必须与io_uring、epoll或Boost.ASIO等底层异步设施结合才能实现真正的异步RPC；标准库无awaitable I/O支持，socket需设为非阻塞并由事件循环驱动，协程仅负责执行流挂起/恢复。
直接说结论：C++20 协程本身不提供异步 I/O 能力，也不能直接发网络请求；它只负责挂起/恢复执行流。要实现异步 RPC 客户端，你必须把协程和底层异步 I/O（如 io_uring、epoll、或第三方库如 libuv/Boost.ASIO）胶合起来——否则协程只是“假异步”，会阻塞线程。
为什么不能只靠 co_await 发 HTTP 或 gRPC 请求？
C++20 标准库至今（C++23 仍未加入）没有提供任何异步 I/O 的 awaitable 类型。像 std::net 这样的提案被多次推迟。这意味着：
-
co_await后面必须是自定义的awaitable类型，不能直接写co_await http_client.send(req) - 所有 socket 操作（connect、send、recv）仍需通过系统调用完成，而这些调用默认是阻塞的
- 若在协程里调用阻塞 socket 函数，整个线程会被卡住，协程失去意义
如何让协程真正异步等待 socket 事件？
核心思路是：把 socket 设为非阻塞模式，用事件循环监听可读/可写状态，再包装成 awaitable。以 Boost.ASIO 为例（它已原生支持 C++20 协程）：
struct rpc_call {
asio::ip::tcp::socket sock;
asio::steady_timer timer;
rpc_call(asio::io_context& ctx) : sock(ctx), timer(ctx) {}
asio::awaitable<std::string> call(std::string_view method, std::string_view payload) {
try {
co_await asio::this_coro::executor;
// 建立连接（非阻塞 connect + async_wait）
sock.open(asio::ip::tcp::v4());
sock.set_option(asio::ip::tcp::socket::non_blocking_io(true));
auto ep = asio::ip::tcp::endpoint(
asio::ip::make_address("127.0.0.1"), 8080);
sock.async_connect(ep, [](const boost::system::error_code&) {});
co_await sock.async_wait(asio::ip::tcp::socket::wait_write, asio::use_awaitable);
// 发送请求（需手动处理 partial write）
std::string req = "POST /" + std::string(method) + " HTTP/1.1\r\n";
co_await asio::async_write(sock, asio::buffer(req), asio::use_awaitable);
// 接收响应（需处理 header/body 分离、EOF 等）
std::array<char, 4096> buf;
size_t n = co_await sock.async_read_some(asio::buffer(buf), asio::use_awaitable);
co_return std::string(buf.data(), n);
} catch (const std::exception& e) {
co_return "ERROR: " + std::string(e.what());
}
}
};
注意：asio::async_write 和 asio::async_read_some 返回的是标准 awaitable，可直接 co_await；但你要自己处理协议解析、粘包、超时、重连等——RPC 不是裸 socket。
立即学习“C++免费学习笔记（深入）”；
绕过 Boost.ASIO：手写最小 awaitable 需要什么？
如果你坚持不用 Boost，想从零封装 epoll + 协程，关键组件有三个：
- 一个全局
epoll_fd和事件循环线程（运行epoll_wait） - 每个待等待的 socket 绑定一个
awaitable对象，含await_ready()、await_suspend(coroutine_handle)、await_resume() -
await_suspend中注册该 socket 到epoll，并保存coroutine_handle到哈希表；事件就绪时从哈希表取出 handle 并resume()
难点不在协程语法，而在：如何安全地在多线程间传递 coroutine_handle；如何避免 epoll_ctl(EPOLL_CTL_DEL) 时协程已销毁；如何统一管理超时和取消。这些正是 Boost.ASIO 和 libexecstream 已解决的问题。
RPC 协议层怎么跟协程对接？
别在协程里解析 Protobuf 或 JSON。正确做法是分层：
- 底层：
transport_layer提供awaitable<bytes> send(bytes)</bytes>和awaitable<bytes> recv()</bytes> - 中间：
rpc_encoder将 request object 序列化为bytes，并将bytes反序列化为 response object - 上层：用户 API 是
awaitable<userresponse> user_service->GetProfile(int64_t id)</userresponse>
这样协程只感知“发送”和“接收字节流”，协议细节被隔离。gRPC 的 grpcpp 目前不支持 C++20 协程（截至 v1.60），所以多数生产项目仍用回调或 std::future 包装；若真要协程化，得自己桥接 CompletionQueue 事件到 awaitable。
最易被忽略的一点：协程栈默认很小（可能仅几 KB），而 RPC 请求/响应可能带大 payload 或深层嵌套结构体。务必用 std::coroutine_traits::promise_type::get_return_object_on_allocation_failure 或显式分配堆内存的 promise，否则大对象序列化时可能栈溢出崩溃。
