grpc c++ 服务端必须先定义 .proto 文件并生成 c++ 代码，否则无法启动；需用 grpc_cpp_plugin 生成 pb.h 和 grpc.pb.h 并链接 libgrpc++ 与 libprotobuf。
gRPC C++ 服务端必须先定义 .proto 文件并生成 C++ 代码
不写 .proto 文件，C++ 侧根本没法启动 gRPC 服务——这不是可选步骤，是强制前置。gRPC 的契约驱动特性决定了接口结构、序列化规则、服务方法都得从 .proto 定义里生成，C++ 不支持运行时动态注册服务或手写 stub。
常见错误：直接照搬 REST 风格写 C++ 类，再试图“挂”到 gRPC 上；结果编译报错找不到 Service::AsyncService 或 Stub 类型。这是因为没运行 protoc 插件生成绑定代码。
- 确保安装了
grpc_cpp_plugin（不是仅装protoc） - 用类似命令生成：
protoc --cpp_out=. --grpc_out=. --plugin=protoc-gen-grpc=grpc_cpp_plugin helloworld.proto - 生成的
helloworld.pb.h和helloworld.grpc.pb.h必须被 C++ 源文件#include，且链接libgrpc++和libprotobuf
同步 vs 异步服务端实现影响线程模型和吞吐量
C++ 的 gRPC 提供两种服务端模式：同步（ServerBuilder::RegisterService + 重写 Service::Method）和异步（AsyncService + Request* + CompletionQueue）。选错会导致 CPU 空转、连接堆积或难以调试的超时。
同步模式适合逻辑简单、IO 少、开发快的场景；但每个 RPC 调用会阻塞一个 gRPC 内部线程，若业务中调用数据库或 HTTP，线程池很容易耗尽。异步模式能复用少量线程处理成千上万连接，但需要手动管理 CompletionQueue 生命周期和 tag 回调。
- 同步服务：继承生成的
Greeter::Service，重写SayHello方法，返回Status - 异步服务：调用
RequestSayHello注册首次请求监听，收到后需手动Finish并再次RequestSayHello续订 - 务必为异步服务单独开线程跑
completion_queue_->Next()，否则请求永远不会被分发
跨语言调用失败大概率是 proto 兼容性或 TLS 配置不一致
Java/Python/Go 客户端连不上 C++ 服务端，90% 不是代码写错，而是协议层没对齐。gRPC 默认走 HTTP/2，而 HTTP/2 对 TLS 有隐含要求：即使本地测试用 insecure_channel，也必须确认两端都禁用了 TLS；一旦某端误启 TLS（比如 Python 用 secure_channel 但 C++ 仍用 InsecureServerCredentials()），连接直接被拒绝，日志只显示 Connect Failed，没有更细错误。
另一个高频坑是 .proto 版本漂移：C++ 服务端用 v1 字段，Python 客户端用 v2 生成的 stub，字段名相同但编号不同，导致解析出空值或 INVALID_ARGUMENT 错误，且无明确提示。
- 统一用
protoc --version核对所有语言环境的 protobuf 编译器版本，建议锁死在 3.21.x 或以上 - 跨语言联调前，先用
grpcurl -plaintext localhost:50051 list确认服务端暴露的服务名是否可见 - 如需 TLS，C++ 侧必须提供 PEM 格式的
server_cert和server_key，不能只传路径字符串——要读成std::string再传给SslServerCredentialsOptions
客户端 Channel 管理不当会导致内存泄漏和连接风暴
C++ 客户端的 Channel 对象不是轻量级句柄，它内部维护连接池、DNS 解析缓存、健康检查状态。频繁新建 Channel（比如每次 RPC 都 new 一个），会快速耗尽文件描述符，且旧连接不会立即关闭，表现为 Too many open files 或大量 ESTABLISHED 连接残留。
更隐蔽的问题是 Channel 的 args 参数未设超时：默认无限等待 DNS 解析或后端响应，造成线程卡死。而 Go/Python 客户端通常默认带 20s 超时，容易误判为 C++ 服务端慢。
-
Channel应作为单例或长生命周期对象持有，不要在函数栈上临时构造 - 显式设置连接参数：
ChannelArguments args; args.SetMaxSendMessageSize(4 * 1024 * 1024); args.SetInt(GRPC_ARG_KEEPALIVE_TIME_MS, 30000); - 调用
stub->SayHello(&context, &request, &response)前，务必初始化ClientContext并设context.set_deadline(std::chrono::system_clock::now() + std::chrono::seconds(5));
C++ 侧最难调试的其实是异步流式 RPC 的生命周期边界——比如客户端取消后，服务端的 Write 是否还安全？ServerContext 的 IsCancelled() 并非实时，需要配合 AsyncNotifyWhenDone 才可靠。这点和其他语言的“上下文取消即刻生效”行为不一致，容易漏掉资源清理。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
