17370845950

Go 的 net/rpc 默认用 gob 序列化，是 Go 原生二进制格式，仅支持同构 Go 系统通信；跨语言会失败，常见错误如 rpc: can't find service method 或 EOF；切换 JSON-RPC 需用 jsonrpc 包并显式调用 ServeConn 和 Dial。

Go 的 net/rpc 默认用什么序列化？

默认用 gob，不是 JSON、不是 Protobuf，是 Go 原生二进制格式。它只保证 Go 客户端和服务端之间能互通，跨语言调用会直接失败。

常见错误现象：rpc: can't find service method 或连接后立刻 EOF，往往是因为客户端用了 JSON 编码，服务端却在等 gob 流。

• gob 要求结构体字段首字母大写（即导出），否则序列化时忽略
• 不支持循环引用，也不支持 func、chan、unsafe.Pointer 等类型
• 服务端注册方法签名必须是 func(*T, *S) error 形式，其中 T 是接收参数，S 是响应结果

如何切换成 JSON-RPC？

用 net/rpc/jsonrpc 替代默认的 gob 编解码器，但注意：它只是把 gob 换成 json，底层仍是 net/rpc 协议，不是 HTTP+JSON 的 REST 风格。

服务端需显式包装 listener：

listener, _ := net.Listen("tcp", ":8080")
for {
    conn, _ := listener.Accept()
    go jsonrpc.ServeConn(conn) // ← 关键：用 ServeConn 而非 HandleHTTP
}

客户端连接时也要用 jsonrpc.Dial：

client, err := jsonrpc.Dial("tcp", "localhost:8080")
if err != nil {
    log.Fatal(err)
}
var reply string
err = client.Call("Arith.Multiply", &args, &reply)

• JSON 不支持 int64 在 32 位环境下的精确传输（JavaScript number 最大安全整数是 2^53-1）
• 空结构体、nil slice、零值字段在 JSON 中可能被省略，而 gob 会保留
• 没有标准 HTTP 头或状态码，调试时不能用 curl 直接发请求

为什么别在生产环境硬套 net/rpc？

它定位是「同构

Go 系统内部轻量通信」，不是通用 RPC 框架。真实项目里容易踩的坑包括：

• 连接复用弱：每个 rpc.Client 对应一条 TCP 连接，高并发下易耗尽 fd
• 超时控制粒度粗：只能设在 client.Call 级别，无法区分网络超时与业务超时
• 无内置重试、熔断、链路追踪，得自己包一层
• 服务发现、负载均衡、协议升级（如从 TCP 切到 gRPC）全要手动实现

如果真需要跨语言或云原生支持，直接上 gRPC-Go（基于 Protobuf + HTTP/2）更稳妥。它的 protoc-gen-go 生成代码天然带上下文、拦截器、流控能力。

自定义序列化器要注意什么？

想换 Protobuf 或 MsgPack？net/rpc 允许传入自定义 ClientCodec 和 ServerCodec，但必须严格实现接口：

type ServerCodec interface {
    ReadRequestHeader(*Request) error
    ReadRequestBody(interface{}) error
    WriteResponse(*Response, interface{}) error
    Close() error
}

关键点：

• ReadRequestHeader 必须能从字节流中解析出 Service.Method 字符串和序列号，否则路由失败
• 所有编码器必须保证 WriteResponse 和 ReadRequestBody 字节顺序一致，否则出现“成功写入但读不出”的静默错误
• 不要在编解码器里做阻塞 IO，比如同步调用另一个 HTTP 接口——这会让整个 RPC 连接卡住

实际项目中，90% 的自定义序列化需求，本质是想解决跨语言或性能问题，这时候该考虑的不是修 net/rpc，而是换框架。