net/rpc 默认不支持 HTTP POST JSON 解析，因其仅处理 gob 编码的 /RPC2 路径请求；需显式注册 JSONCodec 并挂载 handler 才能支持 JSON-RPC。
为什么标准 net/rpc 默认不支持 HTTP POST 体解析
Go 标准库的 net/rpc 默认使用自定义二进制协议（基于 gob 编码），它期望请求体是纯 gob 编码数据，而非 JSON 或表单。如果你用 curl -X POST -H "Content-Type: application/json" 直接发 JSON，服务会报 rpc: can't find service method 或直接 EOF —— 因为它根本没尝试解析 JSON。
- HTTP handler 是
http.ServeMux注册的rpc.DefaultServer内置实现，只响应POST且路径为/RPC2的 gob 请求 - 它不处理
Content-Type: application/json，也不提供 JSON-RPC 2.0 兼容接口 - 若想用 JSON 通信，必须显式注册
rpc.JSONCodec并自己挂载 handler
如何用 net/rpc 暴露一个可被调用的结构体方法
RPC 方法不是任意函数，必须满足严格签名：首字母大写的导出方法、两个指针参数（*Args, *Reply）、返回 error。否则注册时无报错，但客户端调用会提示 method not found。
- 接收参数和回复参数都必须是导出类型（首字母大写），字段也必须导出
- 方法必须是结构体指针接收者，不能是值接收者
- 第二个参数必须是指针类型；如果写成
func (s *Service) Add(args Args, reply *int)，会失败
type Arith inttype Args struct { A, B int }
func (t Arith) Multiply(args Args, reply int) error { reply = args.A * args.B return nil }
启动 RPC 服务时如何同时支持 TCP 和 HTTP
标准 net/rpc 支持多协议共存，但需手动绑定不同 listener。TCP 是默认方式，HTTP 需额外注册 handler 到 http.ServeMux，且路径必须匹配客户端预期（如 /_goRPC）。
- TCP 启动：用
rpc.ServeConn或rpc.Accept，监听net.Listener - HTTP 启动：调用
rpc.RegisterName后，再执行http.Handle("/_goRPC", rpc.DefaultServer)，最后http.ListenAndServe - 注意：HTTP handler 默认只接受
POST，且要求Content-Type为application/octet-stream（gob）或application/json（需提前注册 JSON codec）
客户端调用时如何指定编码器并避免连接复用问题
Go 的 rpc.Client 默认使用 gob，但若服务端启用了 JSON handler，客户端就必须用 rpc.DialHTTPPath + 显式指定路径，并确保服务端已注册 rpc.JSONCodec。否则会出现解码失败或空响应。
立即学习“go语言免费学习笔记（深入）”；
- 用
rpc.DialHTTP会默认访问/RPC2，而你注册的是/_goRPC，路径不匹配直接 404 - 用
rpc.Dial("tcp", addr)时，服务端必须用rpc.Accept或rpc.ServeConn，不能只跑 HTTP server - 短连接场景下，每次
Dial后记得client.Close()；长连接建议复用*rpc.Client实例
client, err := rpc.DialHTTPPath("tcp", "localhost:8080", "/_goRPC")
if err != nil {
log.Fatal(err)
}
defer client.Close()
args := &Args{7, 8}
var reply int
err = client.Call("Arith.Multiply", args, &reply)
if err != nil {
log.Fatal(err)
}
fmt.Printf("Result: %d\n", reply)
Golang 的 net/rpc 看似简单，但协议选择、编码器注册、路径匹配、方法签名这四点只要错一个，就会静默失败或报错模糊。实际部署时，建议优先考虑 gRPC 或 REST+JSON，除非明确需要与旧 Go RPC 客户端兼容。
