双向流在C++ gRPC中必须使用异步API实现，同步API不支持；需在.proto中成对使用stream关键字定义请求和响应，服务端须基于CompletionQueue与状态机驱动读写循环，客户端需主动管理Write/Read生命周期及错误处理。
双向流在 C++ gRPC 中必须用异步 API 实现，同步 API 不支持双向流。 这是很多初学者卡住的第一关：写完 .proto、生成代码、照着 unary 示例改，结果编译失败或运行时崩溃——根本原因是 C++ 的同步服务端只提供 ServerReaderWriter 接口，但它的生命周期和调用模型强制要求你手动管理读写顺序与线程安全，而真正可用的、符合 HTTP/2 流语义的双向流，只能走 AsyncGenericService 或更推荐的 CompletionQueue + ServerAsyncResponseWriter 异步路径。
定义 .proto 时 stream 关键字必须成对出现
双向流的接口声明不是“加个 stream 就行”，而是请求和响应类型都得带 stream：
service ChatService {
rpc ChatStream (stream Message) returns (stream Message);
}
message Message {
string user = 1;
string content = 2;
}
如果只写一边（比如 rpc ChatStream (stream Message) returns (Message)），那就是客户端流式（Client Streaming），不是双向流。生成的 C++ 代码里会对应出 ChatService::AsyncService 下的 RequestChatStream 方法，它返回的是 ServerAsyncReaderWriter，这是唯一能同时收发的句柄。
服务端必须用 CompletionQueue + 状态机驱动
C++ gRPC 双向流没有“开箱即用”的循环读写封装，你得自己维护状态、注册回调、处理完成事件。典型漏掉的点包括：
- 没在
ServerContext上调用AsyncNotifyWhenDone()，导致连接断开时无法感知上下文销毁 - 只调用一次
Read()就停了，没在每次读成功后立刻再发起下一次Read()，结果客户端发第二条消息就卡住 - 在同一个
ServerAsyncReaderWriter上并发调用Write()和Read()，没加锁或没用Next()同步完成队列，引发未定义行为 - 忘记在
Finish()前调用WritesDone()显式关闭写方向，导致客户端永远等不到流结束
核心逻辑骨架必须是“读 → 处理 → 写 → 再读”，且每个操作都要绑定到同一个 CompletionQueue 并用 tag 区分事件类型。
客户端需主动控制 Write() 和 ReaderWriter::WaitForInitialMetadata()
C++ 客户端双向流用 ClientAsyncReaderWriter，常见错误有：
- 调用
Write()后不检查返回值，忽略流已被对端关闭的情况，后续继续写会触发DEADLINE_EXCEEDED或直接 crash - 没在首次
Write()后调用WaitForInitialMetadata()，导致某些服务端（尤其是非 gRPC-native 网关）无法正确建立流上下文 - 用
Read()阻塞等待响应，但没配超时，服务端延迟或丢包时整个线程卡死 - 在流未
Finish()前就析构ClientAsyncReaderWriter，造成资源泄漏或 SIGSEGV
真实项目中建议把读写包装成带重试、限速、背压反馈的状态对象，而不是裸调 API。
最易被忽略的是流的全生命周期边界：HTTP/2 层的流 ID、gRPC 层的 status code、应用层的消息序列号，这三者在异常断连、重连、乱序送达时完全可能错位。不要假设 Write() 成功就等于对方已收到，也不要认为 Read() 返回 EOF 就代表对端优雅关闭——得靠应用层心跳 + 序列号校验兜底。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
