<p>Thrift IDL 生成 C# 代码需用 thrift --csharp -out ./gen-csharp service.thrift，注意 include 路径、命名空间声明及 NuGet 包版本匹配；生成类不可直接 JSON 序列化，客户端调用失败多因 Transport/Protocol 配置或 IDL 版本不一致。</p>
Thrift IDL 文件怎么用 thrift 命令生成 C# 代码
直接跑 thrift 命令就行，但必须指定 --csharp 且路径不能错。IDL 文件里如果用了 include，所有被包含的文件得和主 IDL 在同一目录，或用 -I 显式加搜索路径，否则生成直接报错：Could not open include file "xxx.thrift"。
常见错误是以为加了 --gen csharp 就行——实际命令是 --csharp（没 gen）；还有人把输出目录写成不存在的路径，结果啥也不报、啥也不生成，静默失败。
-
thrift --csharp -out ./gen-csharp service.thrift（最简可用命令） - 多个 IDL：用空格分开，
thrift --csharp -out ./gen *.thrift - 含依赖：加
-I ./includes指定 include 路径 - 生成的
.cs文件默认不带命名空间，靠 IDL 里的namespace csharp xxx控制，漏写这行，C# 代码会全扔进全局命名空间，引用时容易冲突
C# 项目里怎么引用生成的 Thrift 类型和序列化逻辑
生成的代码本质是纯类定义 + 序列化/反序列化方法，不带网络通信能力。你得自己配 Transport 和 Protocol，比如用 TTransport 接 TSocket，再套一层 TBinaryProtocol。
最容易踩的坑是 NuGet 包版本不匹配：官方 Apache.Thrift 包从 0.15 开始移除了对 .NET Framework 的完整支持，.NET 6+ 项目建议用 Apache.Thrift 0.17.x，但注意它不兼容老版 IDL 中的 oneway 或某些异常语法；如果用的是旧版生成代码，别强行升级包。
- 必须引用
Apache.ThriftNuGet 包（不是Thrift或其他同名包） -
TSerializer和TDeserializer只处理内存字节，不涉及网络，别指望它自动发 HTTP 请求 - 跨语言调用时，Protocol 必须和服务端一致：服务端用
TCompactProtocol，客户端也得用，否则解包直接抛TProtocolException - 生成的 client 类（如
MyService.Client）构造函数要传TProtocol，不是TTransport——很多人传错类型，编译不过
Thrift 生成的 C# 类为什么不能直接 JSON 序列化
因为生成类里大量字段是 public virtual、带 [Obsolete] 标记，还有 __isset 内部结构体，主流 JSON 库（System.Text.Json、Newtonsoft.Json）默认会尝试序列化这些，结果要么抛异常，要么输出一堆无意义字段。
这不是 bug，是 Thrift 设计使然：它靠二进制协议保证字段存在性，不依赖 JSON 的可选字段语义。真要转 JSON，只能手动映射到 DTO 类，或者用 Thrift.Serializer 先转 byte[] 再 Base64 编码——但那就不是“JSON 序列化”了。
-
System.Text.Json默认跳过virtual成员，但__isset字段仍可能被扫到，需显式配置IgnoreReadOnlyFields = true - 别给生成类加
[Serializable]或[DataContract]——Thrift 不认这些，加了也没用 - IDL 里用
optional字段，在 C# 生成类中对应Nullable<T>或bool __isset_xxx，JSON 库无法自动理解这种“存在性”，必须业务层判断
Thrift C# client 调用时 Connection refused 或 TApplicationException 怎么查
90% 是 Transport 层没连上，不是业务逻辑问题。先确认 TSocket 构造时的 host/port 和服务端监听地址完全一致（注意 Docker 网络、localhost 在容器内不等于宿主机）；再检查服务端是否真的在运行且没崩在启动阶段（比如 IDL 版本不匹配导致服务加载失败，日志却很安静）。
TApplicationException 这类错误往往意味着协议已通，但服务端返回了异常响应，比如方法名拼错、参数类型不匹配、IDL 版本不一致（服务端用 0.16 生成，客户端用 0.17 生成），此时 Wire 上的数据能收能发，但语义对不上。
- 开
TDebugProtocol包一层，把收发的二进制流打出来，肉眼比对前几个字节是否符合TBinaryProtocol格式（比如 magic number0x80 0x01） - 服务端日志一定要开 DEBUG 级，尤其看
Processor.Process是否被调用，没调用说明请求根本没路由过去 - 别信“连接成功就万事大吉”——Thrift 的
Open()只建 TCP 连接，不验证服务端协议能力，真正的校验在第一次WriteMessageBegin()时才发生
Thrift 的跨语言契约强，但生成代码和运行时绑定非常紧，IDL 改一行，C# 和 Java 两边都得重生成、重新部署，这点很容易被忽略。
