不能直接用于生产环境。net/rpc 默认用 Gob 编码、不跨语言、需手动封装 HTTP、缺乏超时/重试/服务发现，仅适合学习或内网轻量通信，上线前应评估替换为 gRPC 等成熟方案。
Go 标准库 net/rpc 能否直接用于生产环境？
不能直接用于生产。标准库 net/rpc 默认使用 Gob 编码，不跨语言，HTTP 传输层需手动封装，且缺乏超时控制、重试、服务发现等能力。它适合学习 RPC 原理或内网轻量模块间通信，但上线前应评估是否替换为 gRPC、Dubbo-Go 或基于 HTTP/JSON 的自定义方案。
用 net/rpc 实现最简服务端需注意哪些关键点？
服务端必须满足三个硬性条件：结构体字段首字母大写（导出）、方法签名固定为 func(*T, *Args, *Reply) error、方法必须是导出的（首字母大写）。否则注册会静默失败，客户端调用时返回 rpc: can't find service Method。
-
Args和Reply类型必须可被 Gob 编码（即字段可导出，且类型支持） - 服务注册必须在
http.Serve或rpc.Accept启动前完成 - 若用 HTTP 传输，需显式调用
rpc.HandleHTTP()，并确保监听端口未被占用
package mainimport ( "log" "net/http" "net/rpc" )
type Args struct { A, B int }
type Arith int
func (t Arith) Multiply(args Args, reply int) error { reply = args.A * args.B return nil }
func main() { rpc.Register(new(Arith)) rpc.HandleHTTP() log.Fatal(http.ListenAndServe(":1234", nil)) }
客户端调用时为什么总卡住或报 dial tcp :1234: connect: connection refused？
这是最常见的连接问题，根本原因不是代码写错，而是服务端没真正跑起来，或监听地址不对。检查三件事：
- 服务端进程是否仍在运行（
ps aux | grep 1234） - 服务端监听的是
:1234还是127.0.0.1:1234？客户端rpc.DialHTTP("tcp", "127.0.0.1:1234")中地址必须严格匹配 -
防火墙或 Docker 网络是否拦截了端口（本地测试建议先关防火墙或用
curl http://127.0.0.1:1234/debug/rpc验证 HTTP handler 是否生效）
package mainimport ( "log" "net/rpc" )
func main() { client, err := rpc.DialHTTP("tcp", "127.0.0.1:1234") if err != nil { log.Fatal(err) // 注意：这里会直接 panic，实际应加 context.WithTimeout } defer client.Close()
args := &Args{7, 8} var reply int err = client.Call("Arith.Multiply", args, &reply) if err != nil { log.Fatal(err) } log.Printf("Result: %d", reply)}
如何给
rpc.Client.Call加超时和上下文控制？标准
net/rpc不原生支持 context，但可通过封装底层连接实现。最稳妥的方式是用net.DialTimeout控制建连阶段，再对Call使用time.AfterFunc或启动 goroutine + channel 超时判断。更推荐升级到golang.org/x/net/context兼容的封装库，或直接迁移到 gRPC。
- 建连超时：用
rpc.DialHTTPPath+ 自定义http.Transport设置DialContext - 调用超时：必须自己实现 channel select 模式，无法复用
context.Context的取消链 - 不要依赖
client.Close()触发超时清理；超时后应主动cancel()并丢弃该 client 实例
跨语言互通、负载均衡、可观测性这些需求，从一开始就不该指望 net/rpc 解决。它只是 Go 的一个教学级参考实现，别把它当基础设施用。
