grpc c++双向流客户端需用asyncbidistreamingrpc获取unique_ptr，必须调用startcall()后才能write()，read()返回false时须立即finish()；服务端须显式finish()，错误只能通过finish(status)或response中error字段传递；completionqueue析构前必须shutdown并next()完所有tag。
gRPC C++ 双向流接口怎么写 client 侧
客户端发起双向流，核心是调用 stub->AsyncBidiStreamingRpc(&context, &cq) 获取一个 std::unique_ptr<clientasyncreaderwriter></clientasyncreaderwriter>，后续所有读写都靠它。别直接用同步接口——同步双向流在 C++ gRPC 里根本不存在，强行用 stub->BidiStreamingRpc() 会编译失败或运行时 panic。
常见错误现象：Segmentation fault 出现在第一次 Write() 后，往往是因为没调用 StartCall() 或忘了 Finish() 前就释放了 ClientContext；或者 Read() 返回 false 后还继续调用 Read()，触发未定义行为。
- 必须在
Write()前调用StartCall()，否则写操作无效 -
Write()默认非阻塞，但底层缓冲区满时会返回false，需配合WriteLast()或检查返回值 -
Read()和Write()可并发调用，但不能在同一个ClientAsyncReaderWriter上同时多个未完成的Read() - 服务端关闭流后，
Read()返回false，此时应立即调用Finish()并处理状态码
服务端如何正确响应双向流请求
C++ 服务端实现双向流，关键在于重载 Service::AsyncService::RequestBidiStreamingRpc 注册回调，并在回调中 new 一个继承自 ServerAsyncResponseWriter 的类（或用 lambda + ServerAsyncStreamingInterface），再手动调用 Finish() 显式结束流。漏掉 Finish() 会导致连接卡住、内存泄漏。
典型坑：用 ServerContext 的生命周期管理业务对象，结果 ServerContext 在流结束前就被销毁；或者在 Write() 失败后没检查状态就继续发数据，导致 CompletionQueue 混乱。
立即学习“C++免费学习笔记（深入）”；
- 每个流必须绑定独立的
ServerContext，不能复用 -
Write()成功只表示入队成功，不保证送达；失败时status.ok()为false，需终止当前流 - 不要在
OnReadDone()回调里直接调用Write()—— 应通过CompletionQueue投递新任务，避免栈溢出 - 流关闭时，
ServerContext的IsCancelled()可能为true，但不等于流已结束，仍需调用Finish()
异步流里怎么传状态和错误信息
双向流没有“一次返回错误”的机制，错误只能通过 Status 在 Finish() 时传递。想中途通知客户端异常（比如参数校验失败），得自己定义 error 字段塞进 response message，再由客户端解析。gRPC 层不会自动把 exception 转成 status。
常见误区：在 Write() 失败后调用 Finish(Status::CANCELLED)，结果客户端收不到这个 status，因为 Write() 失败本身已让流进入不可写状态，Finish() 被忽略。
- 真正有效的错误传达方式只有两种：提前
Finish()（带非 OK status），或在 response proto 里加oneof { success Success; error Error; } -
Status::ABORTED和Status::INTERNAL区别很大：ABORTED表示客户端可重试，INTERNAL表示服务端故障，客户端通常不应重试 - 如果需要携带调试信息，用
Status::WithDetails()加入google.rpc.Status，但注意 protobuf 版本兼容性（需链接libgrpc++_error_details）
为什么 CompletionQueue 用完不清理就崩溃
CompletionQueue 是 C++ gRPC 异步模型的中枢，所有回调都从它 Next() 出来。但它不是线程安全的，且析构前必须确保没有 pending 的 tag。常见 crash 是在主线程 delete CompletionQueue，而 worker 线程还在 Next() 它。
最容易被忽略的一点：ServerBuilder::BuildAndStart() 内部创建的 CompletionQueue 不归你管，但你自己 new 的（比如 client 侧用于异步流的），必须显式 shutdown + Shutdown() + Next() 直到返回 false，才能 delete。
- 调用
cq_->Shutdown()后，所有未完成的异步操作会以status.ok() == false完成，tag 仍会返回，必须全部Next()掉 - 不要在
Next()循环里直接 deleteCompletionQueue—— 先 break 循环，再单独 shutdown 和 delete - 多线程共用一个
CompletionQueue是可行的，但要确保所有AsyncNext()调用都在同一线程，否则行为未定义
双向流的复杂度不在语法，而在状态机的边界控制：写操作是否真正发出、读操作是否真正结束、错误到底该在哪一层暴露、queue 生命周期和流生命周期谁先谁后——这些地方一松动，就是 core dump 或静默丢包。
