最常见 UNAVAILABLE 原因是服务端未启动、地址错误或 TLS 配置不匹配；C++ 客户端默认明文，若服务端启用 TLS 则客户端必须配 ssl_channel_credentials，否则静默失败。
gRPC C++ 客户端怎么连上服务端不报 UNAVAILABLE
连不上最常见原因是服务端没启动、地址写错，或 TLS 配置不匹配。C++ 客户端默认走明文（insecure），但服务端若启用了 TLS（比如用 ssl_server_credentials），客户端就必须配 ssl_channel_credentials，否则直接返回 UNAVAILABLE，且日志里几乎不提示具体原因。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先用
grpc_cli测试：运行grpc_cli ls localhost:50051，确认服务可访问且能列出服务名 - 客户端创建 Channel 时，明确指定传输方式：
明文用grpc::CreateChannel("localhost:50051", grpc::InsecureChannelCredentials())；
TLS 用grpc::CreateChannel("localhost:50051", grpc::SslCredentials(grpc::SslCredentialsOptions{}))（证书路径需填进SslCredentialsOptions） - 检查防火墙和端口：Linux 上用
ss -tuln | grep 50051看服务端是否真在监听，Windows 用netstat -ano | findstr :50051
如何让 C++ gRPC 客户端支持超时和重试
默认情况下，C++ 的 stub->SayHello(&context, &request, &response) 会无限等待，直到连接断开或服务端返回。必须手动设置 grpc::ClientContext 才能控制行为。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 超时：调用
context.set_deadline(std::chrono::system_clock::now() + std::chrono::seconds(3))，注意单位是绝对时间点，不是相对时长 - 重试：gRPC C++ 1.40+ 支持声明式重试策略，但需在 Channel 创建时启用：
grpc::ChannelArguments args; args.SetInt(GRPC_ARG_ENABLE_RETRIES, 1); auto channel = grpc::CreateChannel(..., args);；再在ClientContext中设置context.AddMetadata("grpc-encoding", "identity")等触发条件（实际重试逻辑依赖服务端响应码和配置的 retry policy） - 更稳妥的做法是应用层重试：捕获
status.error_code() == grpc::StatusCode::UNAVAILABLE或DEADLINE_EXCEEDED后，sleep 后重新发起请求
生成的 *.grpc.pb.h 文件编译报 undefined reference to 'vtable for grpc::Service'
这是典型的链接缺失问题：你用了 gRPC 的服务基类（比如继承了 MyService::Service），但没链接 libgrpc++.a 或对应的动态库。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- CMake 中确保链接顺序正确：
target_link_libraries(my_server PRIVATE grpc++ grpc protobuf)，grpc++必须在grpc前面 - 如果用 pkg-config，链接命令应包含
$(pkg-config --libs grpc++)，不能只写grpc - 检查是否混用了静态/动态版本：比如头文件来自静态构建的 gRPC，但链接的是动态
libgrpc++.so，虚函数表可能不一致 - 确认
protoc和grpc_cpp_plugin版本严格一致，否则生成的代码可能引用了新版符号但链接旧库
为什么 C++ gRPC 服务端处理并发请求很慢，CPU 却不高
常见原因是没开多线程服务器，或者同步阻塞在某个环节。gRPC C++ 默认的 ServerBuilder 是单线程 Reactor 模型，所有 RPC 都在一个线程里串行处理。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须显式设置线程池：
builder.AddListeningPort("0.0.0.0:50051", grpc::InsecureServerCredentials()); auto cq = builder.AddCompletionQueue(); builder.SetMaxMessageSize(4 * 1024 * 1024); auto server = builder.BuildAndStart();—— 这还不够，要额外启动多个线程循环调用cq->Next() - 典型模式是：创建 N 个线程，每个线程执行
while (cq->Next(&tag, &ok)) { /* handle */ }，N 一般设为 CPU 核心数 - 避免在 RPC 处理函数中做耗时同步操作（如文件读写、数据库查询），应转成异步回调或扔进独立线程池，否则会卡住整个 CompletionQueue
- 用
grpc::ServerContext::AsyncNotifyWhenDone()替代同步等待，才能真正发挥异步优势
gRPC C++ 的坑多数藏在链接、线程模型和上下文生命周期里，而不是语法本身。尤其要注意 ClientContext 和 CompletionQueue 的生存期管理——提前析构会导致段错误，漏掉 Finish() 或 NotifyWhenDone() 会导致资源泄漏。这些细节不会报编译错误，但上线后会悄无声息地吃掉内存或 hang 住请求。
