gRPC是Go新服务首选，因生态成熟、跨语言、原生流式支持；Twirp仅适合简单POC或JSON兼容场景；Thrift和net/rpc在新项目中均不推荐。
gRPC 是当前 Go 项目中默认首选，除非你有明确理由不用
如果你正在启动一个新服务、团队有一定工程能力、需要长期维护，gRPC 几乎是唯一合理起点。它不是“最简单”的，但它是“最不后悔”的——生态成熟、跨语言无障碍、流式支持原生、工具链（protoc + grpc-go）稳定可靠。别被“HTTP/2”或“Protobuf”吓住，真正卡住开发的从来不是协议，而是IDL定义是否清晰、错误处理是否统一、调试链路是否可追踪。
- 用
gRPC时，.proto文件就是你的接口契约，必须由服务提供方和调用方共同评审，不能只写完就生成代码了事 - 避免在
.proto中滥用any或嵌套过深的 message，这会让客户端反序列化失败变得难以定位（常见错误：cannot unmarshal proto: unknown field "xxx"） - 调试建议：装
grpcurl工具，用grpcurl -plaintext localhost:50051 list快速验证服务是否在线、接口是否暴露
别为了“轻量”选 Twirp，除非你只要 JSON+HTTP/1.1+零配置
Twirp 确实比 gRPC 上手快：不用装 protoc 插件、不用开 HTTP/2、直接用 curl 就能调通。但它本质是“gRPC 的 JSON over HTTP/1.1 简化版”，牺牲了流式、头部压缩、多路复用等关键优化。一旦业务增长，你很快会遇到两个问题：Twirp 不支持服务端流（server-streaming），也难集成主流服务发现（如 Consul/Nacos 的 gRPC 健康检查探针不兼容 Twirp）。
- 适合场景：内部管理后台的微服务间简单调用、POC 验证、遗留系统快速接入（对方只接受 JSON HTTP）
- 注意：Twirp 默认不带 TLS 双向认证支持，若需 mTLS，得自己 wrap
http.Handler，而gRPC的credentials.TransportCredentials是开箱即用的 - 常见坑：
Twirp的错误码映射是硬编码的（如twirp.Internal→ HTTP 500），无法像 gRPC 那样通过Status.Code()统一做重试策略
Thrift 在 Go 新项目里基本没有优势，老系统迁移除外
Apache Thrift 的 Go 实现（apache/thrift 官方库）长期存在 generator 不稳定、context 传递不自然、error 处理反直觉等问题。比如它的 Go client 方法签名是 func(*args) (*result, error)，但 *args 里没有 context.Context，强行加会导致 breaking change；而 gRPC 所有方法第一个参数必为 context.Context，天然支持超时、取消、trace propagation。
- 仅建议使用场景：已有 Java/Python Thrift 服务且短期内无法重构，Go 客户端需对接
- 性能不是理由：现代
gRPC-Go在吞吐和延迟上已全面优于 Thrift 的 Go binding（尤其小包高频调用） - 真实代价：Thrift IDL 编译后生成的 Go 代码可读性差，字段名大小写转换规则混乱（如
user_id→UserId_），排查字段空值问题极耗时间
别碰 net/rpc，除非你写的是单机工具或教学 Demo
net/rpc 是 Go 标准库里的玩具级 RPC，用 gob 编码，默认走 TCP，**完全不跨语言**。你用它写的 server，Java/Python 客户端根本连不上。即使改用 net/rpc/jsonrpc，也只支持 TCP，不支持 HTTP，无法被 ingress controller（如 Nginx / Traefik）直接路由，更没法做健康检查、限流、鉴权等基础治理。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误现象：
connection refused—— 因为jsonrpc不监听 HTTP 端口，而你却用curl http://localhost:8080去试 - 它强制要求方法签名必须是
func(*T, *U) error，第二个参数必须是指针，且所有字段首字母大写；稍不注意就 panic：“method xxx has wrong number of ins” - 没有中间件机制，日志、metric、trace 全得自己在每个方法里手写，无法复用
真正容易被忽略的点是：RPC 框架选型不是技术问题，而是协作问题。选 gRPC 意味着团队要接受「先写 .proto，再写逻辑」的约束；选 Twirp 意味着放弃流式和未来扩展性；而用 net/rpc 则等于提前给自己埋下服务治理的债务。框架本身不会出错，但选错之后补救的成本，远高于最初多花两小时对齐 IDL 设计。
