应改用 gRPC+Protocol Buffers 替代 Go 原生 net/rpc，因其基于 HTTP/2 多路复用、强制 protobuf 编码、跨语言且支持流控；迁移需转换 proto 文件、手写注册、调优 ClientConn 连接池与重试、严格使用 context 控制超时。
Go 的 net/rpc 默认基于 gob 编码，吞吐低、序列化开销大、不跨语言，生产环境直接用它跑高并发 RPC 几乎必然成为瓶颈。要真正提升效率，得从协议、编解码、连接复用和上下文控制四个层面动手。
换用 gRPC + Protocol Buffers 替代原生 net/rpc
原生 net/rpc 是 Go 专属、无标准 IDL、不支持流控和元数据透传；gRPC 基于 HTTP/2，天然多路复用、头部压缩、双向流，并强制使用 protobuf——二进制紧凑、解析快、跨语言友好。
迁移关键点：
- 将原有
struct定义转为.proto文件，用protoc-gen-go生成 Go stub - 服务端用
grpc.NewServer()替代rpc.NewServer()，注册 handler 而非 struct 实例 - 客户端用
grpc.Dial()获取*grpc.ClientConn，复用它调用多个方法（不是每次调用都新建 conn） - 避免在
.proto中定义嵌套过深或含大字段（如bytes超 1MB），否则触发默认 4MB 的MaxRecvMsgSize限制
禁用反射式服务注册，手写 RegisterXXXService
gRPC 自动生成的 RegisterXXXService 函数内部是纯函数调用，无反射；但如果你用 grpc-gateway 或某些封装库自动注册，可能隐含 reflect.Value.Call，压测时会明显看到 CPU 花在 runtime.reflectcall 上。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 检查生成代码中是否含
srv.RegisterService(&_XXX_serviceDesc, &s)—— 这是安全的 - 禁用所有“自动扫描
service目录并注册”的工具（如某些内部框架脚本） - 若需动态注册逻辑，改用 map[string]func(ctx, req) resp 查表分发，而非
reflect.Value.MethodByName
调整 ClientConn 的连接池与重试策略
grpc.ClientConn 本身已内置连接池，但默认配置偏保守：单个 target 最多 100 个空闲连接、无健康检查、失败后立即返回错误而非自动重试。
高频调用场景下应显式配置：
conn, err := grpc.Dial(addr,
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithBlock(),
grpc.WithDefaultCallOptions(
grpc.MaxCallRecvMsgSize(8 * 1024 * 1024), // 根据实际响应大小调整
),
grpc.WithConnectParams(grpc.ConnectParams{
MinConnectTimeout: 5 * time.Second,
Backoff: backoff.Config{
BaseDelay: 1.0 * time.Second,
Multiplier: 1.6,
Jitter: 0.2,
},
}),
)注意：grpc.WithBlock() 仅用于初始化阶段阻塞等待连接就绪；运行时调用无需且不应加该选项，否则会卡住 goroutine。
用 context.WithTimeout 控制单次调用生命周期
不带超时的 RPC 调用一旦后端卡住，会持续占用 client 端 goroutine 和连接，雪崩风险极高。Go 的 context 是唯一可靠手段。
正确姿势：
- 永远不用
context.Background()直接传给client.Method(ctx, req) - 对下游依赖，设比上游 deadline 少 100–200ms 的 timeout，留出调度余量
- 若需 cancel（如用户主动中断页面请求），用
context.WithCancel，并在 defer 中调用 cancel() - 避免在
for循环内反复创建新 context，应在外层统一构造并传递
最易被忽略的是：gRPC 的 WithTimeout 只控制“本次调用”，不控制连接建立时间——后者由 grpc.WithConnectParams 中的 MinConnectTimeout 控制，两者必须协同设置，否则可能 timeout 触发前连接还没建好。
