必须检查grpc::CreateChannel()返回值是否为nullptr，否则Stub构造后调用会崩溃；TLS配置错误、DNS失败、地址格式不合法（如IPv6未加方括号）均导致静默空指针。
gRPC C++ 客户端初始化失败：找不到 Channel 或 Stub
常见现象是编译通过但运行时报 Segmentation fault，或 nullptr 解引用崩溃。根本原因不是代码写错，而是 Channel 构建失败后没检查就直接传给 Stub::NewStub()。
必须检查 grpc::CreateChannel() 返回值是否为 nullptr，尤其在 TLS 配置错误、DNS 解析失败、目标地址格式不合法（比如漏了 ipv4: 前缀）时，它会静默返回空指针。
-
grpc::CreateChannel("localhost:50051", grpc::InsecureChannelCredentials())仅适用于本地明文通信；生产环境用grpc::SslCredentials()时，必须确保ca.pem路径正确且内容可读 - IPv6 地址需显式加方括号：
"[::1]:50051"，否则CreateChannel会解析失败 - 异步调用前务必确认
Channel处于GRPC_CHANNEL_READY状态，可用channel->GetState(true)主动触发连接并轮询
同步调用卡死：WaitForConnected 不生效或超时无效
这不是网络延迟问题，而是 gRPC C++ 的同步阻塞语义和底层连接状态机不匹配导致的。调用 channel->WaitForConnected(...) 后仍卡在 stub->SayHello(...)，往往因为连接虽“就绪”但服务端尚未完成 HTTP/2 settings 帧交换。
真正有效的做法是：用 CompletionQueue + 异步 API 绕过阻塞点，或者至少在同步调用前加一层轻量探测——发一个空的 HealthCheckRequest（如果服务启用了 health check）。
立即学习“C++免费学习笔记（深入）”；
- 不要依赖
WaitForConnected的超时参数，它只控制等待“连接建立”，不保证服务端已准备好接收 RPC - 同步调用默认无超时，必须显式设置
grpc::ClientContext::set_deadline()，否则 DNS 暂时不可达时会卡住整整 20 秒（gRPC 默认 connect timeout） - 调试时用
GRPC_VERBOSITY=DEBUG GRPC_TRACE=api,connectivity_state环境变量看真实状态流转
Protobuf 编译产物链接失败：undefined reference to 'google::protobuf::...
链接阶段报一堆 google::protobuf::internal::ArenaImpl::... 未定义，说明你的项目链接了 gRPC 库，但没链接 Protobuf 运行时库，或者版本不匹配。
gRPC C++ 不自带 Protobuf 实现，必须单独提供 libprotobuf。CMake 中不能只写 target_link_libraries(myapp grpc++)，漏掉 protobuf::libprotobuf 是最常见错误。
- 用
find_package(protobuf REQUIRED)后，链接时必须包含${PROTOBUF_LIBRARIES}或protobuf::libprotobuf（取决于 CMake 版本） - 确保 gRPC 和 Protobuf 的构建 ABI 一致：都用
-std=c++17、都禁用 exceptions（-fno-exceptions）或都启用，混用会导致符号不兼容 - 静态链接时注意
libprotobuf.a和libgrpc.a的顺序：Protobuf 必须在 gRPC 之后出现，否则链接器找不到其依赖的符号
流式 RPC 内存泄漏：客户端反复创建 ClientReaderWriter 后程序 RSS 持续上涨
不是你忘了 delete，而是 gRPC C++ 的流对象内部持有 CompletionQueue 和缓冲区，且不会在析构时自动 flush 或 cancel 挂起的 ops。尤其在异常路径下（比如 Write() 返回 false 后直接 return），残留的 pending read/write 会持续占用内存。
必须显式调用 Finish() 并等待其完成，哪怕只是想提前退出流。更稳妥的做法是统一用 RAII 封装，确保 Finish() 在作用域结束时执行。
- 不要依赖
ClientReaderWriter析构函数做清理；它的析构是轻量的，不等 RPC 结束 - 每次
Write()或Read()后必须检查返回值，false表示流已关闭或出错，此时应立刻调用Finish() - 若使用多个
CompletionQueue，确保Finish()调用和所有 pending op 使用同一个队列，否则可能死锁
最麻烦的其实是错误传播链太长：一次 DNS 失败 → Channel 初始化为空 → Stub 构造成功但内部 channel 为空 → 同步调用卡死 → 日志里只看到 “Deadline Exceeded” —— 实际根因在第一行 CreateChannel。这种隐式失败模式，得靠早期状态断言和环境变量追踪才能快速定位。
