net/rpc+JSONRPC存在连接复用缺失、超时粗粒度、无服务发现、无法动态卸载等问题，易导致阻塞读、注册失败、字段未导出等错误；需显式设deadline、规范注册名与结构体字段导出。
为什么直接用 net/rpc + JSONRPC 会出问题
Go 标准库的 net/rpc 虽然轻量，但默认基于 HTTP 的 jsonrpc 实现不支持连接复用、超时控制粒度粗、无服务发现能力，且 Server.Register 后无法动态卸载服务。线上环境一旦遇到节点宕机或网络抖动，客户端会卡在阻塞读，http.DefaultClient 的底层 Transport 未配置时甚至会无限等待。
常见错误现象包括：read tcp 10.0.1.2:54321->10.0.1.3:8080: i/o timeout（实际是底层 TCP 连接未设 deadline）、rpc: can't find service method（注册名大小写/包路径不一致）、调用返回 nil 但无错误（结构体字段未导出）。
- 必须显式调用
conn.SetDeadline或使用context.WithTimeout包裹 RPC 调用 - 服务端注册时用
rpc.RegisterName("UserService", &userSvc)，避免匿名结构体导致反射失败 - 所有传输结构体字段首字母大写，否则 JSON 编码为
null
如何让 Go RPC 支持多协议与服务发现
硬编码 IP+端口必然不可维护。真实场景下需解耦调用方与提供方地址，典型做法是引入中心化注册中心（如 etcd / Consul）+ 客户端负载均衡（如 round-robin + 健康检查）。
关键不在“怎么连”，而在“连之前怎么知道连谁”。建议用 go.etcd.io/etcd/client/v3 实现服务注册：服务启动时写入 /services/user/10.0.1.2:8080，TTL 设置为 10 秒；客户端监听该前缀，本地缓存可用 endpoint 列表，并定期 ping 检查存活。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免轮询 etcd —— 用
client.Watch监听变更，减少请求压力 - 客户端缓存 endpoint 时，用
sync.Map存储，避免并发读写 panic - 不要把 gRPC 和 HTTP/JSON-RPC 混在同一端口 —— gRPC 用
grpc.NewServer()单独监听，HTTP 接口走http.ServeMux分离
怎样用 gRPC 替代标准 net/rpc 实现高可靠 RPC
gRPC 是当前 Go 分布式 RPC 的事实标准，核心优势不是性能，而是成熟生态：grpc-go 内置流控、重试、deadline 透传、TLS 双向认证，且 Protocol Buffer 强类型定义天然规避字段错位问题。
关键实操点：定义 .proto 文件后，用 protoc --go_out=. --go-grpc_out=. user.proto 生成代码；服务端实现 UserServer 接口，客户端用 grpc.DialContext(ctx, addr, grpc.WithTransportCredentials(insecure.NewCredentials())) 连接（生产务必换为 credentials.NewTLS(...)）。
- 必须设置
grpc.WithBlock()+grpc.WithTimeout(3 * time.Second)，否则DialContext可能立即返回未就绪连接 - 客户端拦截器里加
ctx, cancel := context.WithTimeout(ctx, 2*time.Second)，确保单次 RPC 不超过阈值 - 服务端方法签名必须为
func(ctx context.Context, req *UserRequest) (*UserResponse, error)，少一个context.Context参数就会编译失败
为什么序列化选 Protocol Buffer 而不是 JSON
JSON 看似简单，但在分布式 RPC 中隐患明显：字段名拼写错误难发现、浮点数精度丢失（如 1234567890123456789.0 转成 float64 后末尾变 0）、无版本兼容机制（v1 字段删掉后 v2 客户端发来旧结构体直接 panic）。Protocol Buffer 通过 optional / oneof / 字段 tag 控制兼容性，且二进制体积比 JSON 小 60%+，对带宽敏感场景很关键。
容易被忽略的一点：Go 的 protobuf-go 默认启用 UnknownFields，但若服务端升级了 proto 定义而客户端未更新，旧客户端发来的未知字段会被静默丢弃 —— 开发期应在 UnmarshalOptions{DiscardUnknown: false} 下测试兼容性。
- 所有 message 必须从 1 开始编号，跳号（如 1, 2, 4）会导致反序列化失败
- enum 值 0 必须为保留项（如
UNKNOWN = 0;），否则新字段默认值无法识别 - 不要在 proto 中定义复杂嵌套逻辑 —— 业务校验放在 Go 层，proto 只管数据契约
真正麻烦的从来不是“怎么写通一个 RPC 调用”，而是当 200 个微服务互相调用、每天发布 10+ 次、网络分区频繁发生时，你的序列化格式是否扛得住字段演进，服务发现能否在 3 秒内剔除故障节点，以及日志里那条 context deadline exceeded 到底来自哪一层超时配置。
