Go中用Thrift启动服务前必须先用thrift命令行工具根据IDL生成Go代码，否则import会报错；需选用TThreadPoolServer等支持并发的服务器，客户端需自行实现超时和重试，且注意i32/i64与Go int类型宽度差异。
Go 里用 thrift 启动服务前，必须先生成 Go 代码
Thrift 不是开箱即用的 RPC 库，它依赖 IDL（接口定义文件）生成各语言的桩代码。Go 官方不内置生成器，得靠 thrift 命令行工具。没这步，import 生成的包会直接报错 no such file or directory。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保安装的是支持 Go module 的 Thrift 版本（推荐 0.18.0+），旧版生成的代码可能用
github.com/apache/thrift/lib/go/thrift，新版默认用github.com/apache/thrift/lib/go/thrift/v0_18这类带版本路径的导入，混用会编译失败 - IDL 文件里别写 Go 不支持的类型（比如
set<i64>在 Go 里会生成[]int64，但map<string, binary>中的binary会被转成[]byte，没问题；而union类型在 Go 生成器中默认不启用，需加--gen go:allow_unions参数才生成 - 生成命令示例：
thrift --gen go -out ./gen/ service.thrift，生成后记得把./gen/gen-go目录重命名为./gen（新版默认输出到gen-go，但 Go module 路径常按./gen引用）
TServer 选型：别默认用 TSimpleServer 上生产
TSimpleServer 是单 goroutine 处理所有请求，吞吐低、无并发，只适合本地调试。线上服务至少得用 TThreadPoolServer 或 TNonblockingServer（后者需搭配 TNonblockingTransport 和 epoll/kqueue）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
TThreadPoolServer最常用：通过thrift.NewTThreadPoolServer构建，注意numWorkers别设成 CPU 核数的 10 倍——Go runtime 调度本身已很高效，盲目开大量 worker 反而增加 GC 压力和上下文切换开销；建议从runtime.NumCPU() * 2开始压测调整 - 若用
TNonblockingServer，Go client 必须配TNonblockingTransport，否则连接会卡死；且该 server 不支持 HTTP transport，别跟THttpClientTransport混搭 - 所有 server 都要显式调用
server.Listen()和server.Serve()，漏掉Serve()就是静默不响应
Go client 连接 Thrift 服务时，超时和重试得自己兜底
Thrift Go 库的 TTransport 层（如 TBufferedTransport）本身不提供连接超时、读写超时、自动重试机制。一旦网络抖动或服务端卡住，client 会无限阻塞在 transport.Open() 或 client.Call() 上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
thrift.NewTSocketConf配置底层 socket：&thrift.TSocketConf{Timeout: 5 * time.Second}，这个 timeout 控制的是 TCP connect 阶段；读写超时得靠 transport wrapper，例如套一层thrift.NewTBufferedTransportConf并传入thrift.DefaultTConfiguration().SetTimeout(3 * time.Second) - 重试逻辑不能交给 thrift 层——它不保证幂等性。要在业务层判断错误类型：
err是*net.OpError或thrift.TTransportException且Type() == thrift.END_OF_FILE时，才考虑重试 - 别在同一个
TTransport实例上并发调用多个方法：Thrift Go client 不是线程安全的，必须 per-request 新建 transport + protocol + client，或用连接池（如thrift.NewTTransportPool）管理复用
跨语言调用时，i32/i64 和 Go int 类型宽度不一致是高频坑
Thrift IDL 的 i32 在 Go 里生成为 int32，i64 是 int64，但很多 Go 开发者习惯用原生 int（32 位系统下是 32bit，64 位下是 64bit）。混用会导致 struct 初始化失败、JSON 序列化字段丢失、甚至 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- IDL 中所有整数字段明确用
i32或i64，避免用i16除非真需要节省空间；Go 侧一律用生成的类型（如req.UserId *int64），别强转成int - 如果要用 JSON 传输（比如调试用 curl），注意
json.Marshal默认忽略 nil 指针字段；生成的 struct 字段全是指针，得手动解引用或用thrift.NewTJSONProtocol替代标准 JSON - Java/C++ client 传来的
i32若超过 Goint32范围（比如负数被当成 uint32 解析），问题往往出现在对方序列化时用了错误的字节序或 sign 扩展方式——这时候得查双方 thrift 版本是否一致，以及 transport 是否用了TCompactProtocol（推荐）而非TBinaryProtocol（易出符号问题）
IDL 改动和生成代码更新不同步，比网络超时更难排查——因为错误发生在编译期或运行期静默数据错乱，不是 panic。
