自定义Thrift传输层必须继承TTransport并实现open/close/read/write/flush等纯虚函数；需手动处理TCP粘包（加4字节长度前缀）、避免std::string截断二进制数据、显式绑定传输与协议，且read/write须严格遵循网络字节序与缓冲区管理。
Thrift 自定义传输层必须继承 TTransport 类
直接写裸 socket 读写是行不通的，Thrift 的序列化器（如 TBinaryProtocol）只认 TTransport 接口。你得实现它的纯虚函数：open()、close()、read()、write()、flush()，以及可选的 peek() 和 consume()。漏掉 flush() 是常见错误——TCP 缓冲区不手动刷，对端永远收不到完整包。
典型陷阱：在 read() 中返回 0 不代表 EOF，而是“暂时没数据”，必须配合非阻塞 + select() 或用阻塞模式并确保对端正确关闭连接；否则 Thrift 会卡死在 readAll() 内部循环里。
二进制协议下必须严格遵循长度前缀格式
Thrift 的 TBinaryProtocol 默认不自带帧头，它假设传输层已解决粘包问题。如果你的自定义传输层走裸 TCP，就必须自己加长度字段（比如 4 字节 network byte order 的 int32），并在 read() 中先读长度、再读对应字节数。否则反序列化必然失败，报错类似 protocol error: bad version identifier 或直接崩溃在 readByte()。
-
write()先写 4 字节长度（htonl(len)），再写实际数据 -
read()分两步：先读 4 字节转成 host order 长度n，再循环读满n字节（不能只调一次recv()） - 别用
std::string存二进制数据——\0会导致截断；改用std::vector<uint8_t></uint8_t>或folly::IOBuf
构造服务时要显式绑定自定义传输和协议
不能只替换传输层就完事。Thrift 的 TServer 初始化链路是：socket → TTransport → TProtocol → 处理器。你得把自定义传输套进协议里，再喂给服务器：
立即学习“C++免费学习笔记（深入）”；
auto transport = std::make_shared<MyCustomTransport>(sockfd); auto protocol = std::make_shared<TBinaryProtocol>(transport); auto handler = std::make_shared<MyServiceHandler>(); auto processor = std::make_shared<MyServiceProcessor>(handler); TSimpleServer server(processor, transport, protocol, protocol); // 注意：这里传两次 protocol，因为 TServe r需要 input/output 协议
漏传或传错类型（比如把 TBufferedTransport 套在你的自定义传输外面）会导致协议解析错乱——例如整型字段被当字符串读，或结构体字段全为默认值。
调试时优先检查 read() 返回值和缓冲区状态
绝大多数序列化失败不是协议写错，而是传输层底层读写异常没暴露出来。务必在 read() 里检查 recv() 返回值：-1 要看 errno（EAGAIN 可重试，ECONNRESET 必须关连接），0 表示对端关闭，此时应抛 TTransportException 而不是静默返回。
另一个隐藏坑：自定义传输的缓冲区如果复用同一块内存（比如内部 std::vector 没 clear 就 reuse），旧数据残留会导致协议解析错位——建议每次 read() 前重置 buffer size，write() 后清空输出缓冲。
真实场景中，跨语言通信时还要注意字节序一致性（Java/Python 默认大端，C++ htonl 正确），以及 Thrift 版本兼容性（0.13+ 对 optional field 的编码有变更，老客户端连新服务可能静默丢字段）。
