net/rpc 不适合现代微服务生产环境，因其缺乏高并发支撑、跨语言能力、强安全机制和可观测性；仅适用于同构Go小型内部系统快速原型或轻量级模块通信。
net/rpc 不适合现代微服务生产环境，仅适用于同构 Go 小型内部系统的快速原型或轻量级模块通信。
为什么 net/rpc 在生产中要谨慎使用？
它不是设计来扛高并发、跨语言、强安全或可观测性的——这些是生产系统的刚需。
-
gob编码：仅 Go 原生支持，Python/Java/Node.js 客户端无法直连，扩展性归零 - 无内置超时控制：
client.Call默认阻塞，不设context或连接/读写 deadline 会卡死 goroutine - 无流式通信能力：不能做 server-push、实时日志推送、长任务进度通知等常见业务场景
- 错误反馈模糊：网络中断、序列化失败、服务 panic 都统一返回
error，难以区分重试策略 - HTTP 模式（
rpc.HandleHTTP()）用的是http.Serve，不兼容标准中间件（如 JWT 鉴权、OpenTelemetry 注入）
net/rpc 真正合适的使用场景
它存在的意义不是替代 gRPC，而是“够用且省事”的窄带通信。
- 同一团队、全栈 Go 的运维工具链：比如配置下发 agent、本地监控采集器调用主控 RPC 接口
- 单机多进程协作：用
unixsocket 替代 TCP（net.Listen("unix", "/tmp/myrpc.sock")），规避网络层开销 - CI/CD 流水线中的临时服务通信：生命周期短、无横向扩展需求、无需 TLS
- 教学/POC 快速验证逻辑：3 分钟写出服务+客户端，聚焦业务而非协议胶水
如果坚持用 net/rpc，必须补哪些硬伤？
跳过这一步，上线等于埋雷。
- 加 TLS：用
crypto/tls包包装net.Listener，否则所有参数（含密码、token）明文裸奔 - 设超时：客户端必须用
rpc.DialHTTP+ 自定义http.Transport，或自己封装net.DialTimeout；服务端用conn.SetDeadline防堆积 - 结构体字段必须导出：未大写的字段在
gob序列化时被静默丢弃，调试时表现为 “参数没传过去” - 错误不可忽略：
client.Call返回err != nil时，*reply值是未定义的，不能直接解引用 - 别注册全局变量实例：用
rpc.RegisterName("Svc", &MyService{})而非rpc.Register(new(MyService))，避免方法接收者指针失效
package mainimport ( "crypto/tls" "net" "net/rpc" "time" )
func main() { listener, _ := tls.Listen("tcp", ":80
01", &tls.Config{ Certificates: []tls.Certificate{...}, ClientAuth: tls.NoClientCert, })
for { conn, err := listener.Accept() if err != nil { continue } // 强制设置读写超时，防慢连接耗尽资源 conn.SetDeadline(time.Now().Add(30 * time.Second)) go rpc.ServeConn(conn) }}
真正需要长期维护的服务间通信，请直接上
gRPC。它的 HTTP/2 多路复用、protobuf 跨语言、原生 context 支持、丰富生态（grpc-gateway、opentelemetry-go）不是“可选项”，而是生产环境的底线。把net/rpc当玩具用可以，当主力用，代价迟早浮现。
