RCF才是C++项目的首选，因其专为C++设计、支持零拷贝和硬实时特性；gRPC和Thrift本质是跨语言框架，C++仅是目标之一，存在HTTP/2栈开销、内存分配隐患及Windows兼容性问题。
Thrift 在 C++ 中不是开箱即用的“高性能 RPC 框架”，它默认生成的是同步阻塞式通信，真正高性能（高并发、低延迟）必须手动选对传输层、协议层和服务器模型——否则很容易卡在 TBufferedTransport 或 TThreadPoolServer 上。
怎么生成 C++ 可用的 Thrift 接口代码
Thrift IDL 文件（如 service.thrift）需用官方编译器生成 C++ 代码，关键在于加 --gen cpp2 而非旧版 --gen cpp：
-
thrift --gen cpp2 service.thrift生成现代 C++14+ 接口，支持异步客户端、folly::SemiFuture、零拷贝序列化 - 旧
--gen cpp生成的代码无异步支持，TProcessor是单线程模型，吞吐瓶颈明显 - 生成目录为
gen-cpp2/，核心头文件是service_types.h和service.h，需确保-Igen-cpp2加入编译路径
为什么 C++ 服务端不能直接用 TThreadPoolServer
TThreadPoolServer 是阻塞式线程池，每个请求独占一个 OS 线程，连接数一多（比如 >500）就内存暴涨、上下文切换严重。生产环境应优先选：
-
apache::thrift::SimpleThreadManager+apache::thrift::TAsyncServerSocket：基于libevent的事件驱动，单线程可支撑数千连接 - 或更进一步用
apache::thrift::RocketServerChannel（需启用rocket协议），支持流控、优先级、请求合并 - 务必禁用
TBufferedTransport：它会在内存中缓存整包数据，大请求易 OOM；改用THeaderTransport（默认）或TDuplexChannel
C++ 客户端如何避免同步等待拖垮性能
默认生成的客户端是同步阻塞的，调用 client->getUserName(…) 会卡住当前线程。要并发调用，必须用异步接口：
立即学习“C++免费学习笔记（深入）”；
- 调用
client->future_getUserName(userId)（返回folly::SemiFuture<:string></:string>） - 配合
folly::EventBase驱动：eb.runInEventBaseThread([&] { … }); - 传输层必须用
THeaderTransport+TCompactProtocol，否则异步通道无法识别帧边界 - 别忘了设置超时：
channel->setTimeout(std::chrono::milliseconds(300));，否则网络抖动时请求永久挂起
跨语言互通时最容易被忽略的兼容点
Java/Python/Go 客户端能连上 C++ 服务，不代表语义一致。以下三点不检查，上线后必出诡异 bug：
- 所有结构体字段必须显式加
required/optional修饰，C++ 生成代码对optional字段做std::unique_ptr包装，而 Python 默认全 optional，字段缺失时行为不同 - 枚举值必须用
enum MyEnum { VAL1 = 1, VAL2 = 2 }显式赋值，否则不同语言底层整型值可能错位 - 时间类型统一用
i64 timestamp_ms（毫秒级 int64），别用struct Time自定义类型——Thrift 不保证跨语言 struct 序列化字节对齐
Thrift 的“跨语言”是协议层兼容，不是行为层兼容；C++ 的零拷贝和异步能力得靠手动激活，不是生成代码就自动生效。
