应选gRPC；net/rpc仅适用于内部工具或原型验证，缺乏跨语言支持、HTTP/2、流式传输及服务治理能力，而gRPC具备多语言互通、契约驱动、可观测性与生态集成等生产级特性。
用 net/rpc 还是 gRPC？先看场景再选框架
标准库 net/rpc 适合内部工具、低并发调试服务或原型验证，但不建议用于生产级微服务。它默认用 Go 自定义编码（gob），跨语言能力为零，HTTP/2、流式、拦截器、服务发现全都不支持。而 gRPC 是工业级选择——尤其当你需要多语言互通、可观测性、流控或与 Consul/Nacos 集成时，gRPC 的 protoc + protobuf 契约驱动模式能直接规避接口不一致问题。
常见错误现象：net/rpc 客户端调用返回 rpc: can't find method，往往是因为方法签名不满足规则（比如第二个参数不是指针、返回值不是 error）；而 gRPC 编译期就报错，比如 undefined: pb.NewGreeterClient，基本是 protoc 没生成或 import 路径不对。
-
net/rpc：仅限单语言、无服务治理、QPS -
gRPC：必须用protoc --go_out=.+--go-grpc_out=.两步生成代码，缺一不可 - 别试图给
net/rpc加注册中心——它没预留扩展点；要用服务发现，直接切gRPC
proto 文件怎么写才不踩坑
Protobuf 不是“随便写完编译就行”，字段编号、包名、service 命名直接影响生成代码的可用性和向后兼容性。最常被忽略的是 syntax = "proto3"; 必须首行声明，否则 protoc 默认按 proto2 解析，导致空字符串、0 值字段丢失。
使用场景：一个用户服务要支持分页查询，别在 GetUserRequest 里塞 int32 page_size = 3; 和 int32 page_number = 4; ——这会让客户端必须填两个参数，且无法表达“不限制数量”。正确做法是用 optional int32 page_size = 3;（proto3 v3.15+ 支持）或定义 int32 page_size = 3 [default = 20];。
- 所有 message 字段编号从 1 开始连续，跳号（如 1, 2, 4）会浪费 wire 编码空间
-
package名必须小写，且与 Go 包路径一致（如package user;→import "xxx/user"） - service 名不要带下划线，
UserService比User_Service更安全，避免生成代码里出现非法标识符
gRPC 客户端连接池和超时必须手动配
gRPC 的 grpc.Dial 默认不启用连接池，每次 Call 都可能新建 TCP 连接——高并发下直接打满文件描述符。同时，不设超时的客户端会卡死在阻塞调用上，拖垮整个 goroutine 调度器。
性能影响：未配置连接池时，1000 QPS 下 fd 数暴涨 3–5 倍；未设超时，单个慢请求可让整批 goroutine 等待数秒甚至分钟。
- 连接池靠
grpc.WithTransportCredentials+grpc.WithBlock()不够，得加grpc.WithConnectParams(grpc.ConnectParams{MinConnectTimeout: time.Second * 20}) - 超时必须在每次
Call时传context.WithTimeout，全局 Dial 选项里的grpc.WithTimeout已废弃 - 别信 “gRPC 自动重连” ——它只在首次 Dial 失败时重试，连接中途断开需自己监听
connectivity.State并重建 client
流式 RPC 的 context 取消时机很关键
双向流（Bidirectional Streaming）中，如果客户端提前 cancel context，服务端 Recv 会立即返回 io.EOF，但服务端仍在往 stream 写数据的话，会触发 transport is closing 错误——这不是 bug，是流已关闭后的正常行为。
容易踩的坑：在服务端 goroutine 里循环 Send 数据时，没检查 ctx.Err() 就强行写，导致 panic 或日志刷屏。
- 服务端流式 handler 中，每次
Send前必须用if err := ctx.Err(); err != nil { return err }检查 - 客户端用
stream.Context().Done()监听取消，而不是依赖stream.Recv()返回的 error 判断流是否结束 - 流式场景下，
grpc.EmptyCallOption无效，所有选项必须在grpc.Dial时设置，不能 runtime 动态改
真正难的不是写通第一个 RPC，而是让每个流、每次重试、每条链路都可控。gRPC 的契约、连接、上下文三者耦合极深，漏掉任意一环，线上就表现为偶发超时或连接泄漏。
