net/rpc客户端易连不上服务，因默认仅支持HTTP POST的application/json或application/gob编码，且需服务端显式注册http.Handle路由（如"/RPC2"），而rpc.ServeConn/rpc.Accept不走HTTP，导致rpc.DialHTTP超时或报错。
为什么直接用 net/rpc 写客户端容易连不上服务？
因为 net/rpc 默认只支持 HTTP POST 的 application/json 或 application/gob 编码，且要求服务端显式注册 http.Handle 路由（如 "/RPC2"），而多数人只调用 rpc.ServeConn 或 rpc.Accept——这压根不走 HTTP，客户端用 rpc.DialHTTP 必然超时或返回 "invalid character '。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 确认服务端是否真正启用了 HTTP RPC：检查是否调用了
http.Serve且注册了rpc.HandleHTTP() - 若服务端是纯 TCP 模式（常见于内网微服务），客户端必须用
rpc.Dial("tcp", "addr:port")，不能用DialHTTP - Gob 编码要求 client/server 结构体字段名首字母大写且类型完全一致，否则解码失败无明确提示，建议初期先用 JSON 编码调试
如何让 Go RPC 客户端支持超时和重试？
net/rpc 原生不提供超时控制，Call 和 Go 方法都阻塞到底。必须靠封装底层连接实现。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
net.DialTimeout("tcp", addr, timeout)替代rpc.Dial，控制建连阶段超时 - 对每个
client.Call操作，用context.WithTimeout包裹，并在 goroutine 中监听 context.Done()，收到 cancel 后主动关闭底层 conn（需反射获取client.conn并调用Close()） - 重试不宜在 RPC 层做：幂等性需业务判断，简单轮询可能放大雪崩；推荐外层用
backoff.Retry（github.com/cenkalti/backoff）配合自定义backoff.Context
gRPC 替代方案里，grpc.Dial 的 WithBlock 和 WithTimeout 到底要不要开？
这两个参数常被误用。WithBlock 会让 grpc.Dial 阻塞直到连接建立或超时，看似“可靠”，实则破坏 gRPC 的连接复用与健康探测机制；WithTimeout 已被标记为 deprecated，实际生效的是 context.WithTimeout 传给 Invoke 或 NewClientStream。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产环境禁用
WithBlock：gRPC 客户端默认异步建连 + 连接池，首次Call会自动等待连接就绪，无需阻塞 Dial - 必须设超时？在每次调用时传入带 timeout 的 context：
ctx, _ := context.WithTimeout(context.Background(), 5*time.Second)，再传给client.Method(ctx, req) - 连接级健康检查用
WithKeepaliveParams，不是靠 Dial 参数兜底
JSON-RPC 2.0 客户端怎么避免手动拼 request/response？
手写 map[string]interface{} 构造 JSON-RPC 请求体极易出错：id 类型不一致、缺失 jsonrpc 字段、error 结构嵌套错误。更麻烦的是 response 解析要反复 type assert。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
github.com/ethereum/go-ethereum/rpc（轻量，无依赖）：它内置Client支持自动序列化方法调用，且能绑定 struct 到响应字段 - 若需完全控制，用
encoding/json+ 预定义结构体：type Request struct { JSONRPC string `json:"jsonrpc"`; Method string `json:"method"`; Params []interface{} `json:"params"`; ID int `json:"id"` }，别用泛型 map - 务必校验 response 中的
jsonrpc字段是否为"2.0"，不少服务端返回"2.0\n"导致解析失败
net/rpc、gRPC、JSON-RPC 三者底层通信模型和错误传播路径完全不同，混用 Dial 方法是最常见的硬伤。 
