rpc.Register不能处理私有字段或interface{}参数，因gob仅序列化导出字段且不支持interface{}动态类型推导，未导出字段被忽略导致零值，interface{}反序列化失败引发panic或方法签名不匹配。
为什么 rpc.Register 不能处理私有字段或 interface{} 参数
Go 的 net/rpc 默认用 encoding/gob，它只序列化导出（首字母大写）字段，且对 interface{} 这类类型依赖运行时反射——而 gob 的反射逻辑不支持动态类型推导，一遇到未注册的类型就 panic 或静默丢弃。常见现象是客户端传了 struct，服务端收到全零值；或者调用返回 rpc: can't find service method，实际是参数反序列化失败导致方法签名不匹配。
- 必须确保所有参数、响应结构体字段全部导出，且类型在 gob 注册表中存在（gob.Register 可显式注册，但无法覆盖嵌套泛型）
- 避免在 RPC 方法签名里直接用
interface{}或map[string]interface{}；改用具体结构体，或提前用gob.Register注册常用 map/slice 类型 - 若需动态参数，不如把 JSON 字符串当
string传，在 handler 内部用json.Unmarshal解析——至少可控、可 debug
jsonrpc.ServeConn 和 rpc.ServeConn 混用会直接报 invalid character
这不是配置问题，而是协议帧格式根本不同：rpc.ServeConn 期望 gob 二进制流，jsonrpc.ServeConn 期望换行分隔的 JSON 对象。客户端如果用 rpc.Dial 连接了 jsonrpc.ServeConn 启动的服务，发出去的是 gob 编码字节，服务端用 JSON 解析器读，第一字节就是乱码，立刻报 invalid character '' looking for beginning of value。
- 服务端用了
jsonrpc.ServeConn，客户端必须用jsonrpc.Dial或jsonrpc.NewClient - 反之亦然：gob 模式下不能用 jsonrpc 包的 client
- 调试时别用
curl直连——JSON-RPC over TCP 不是 HTTP，没有状态码和 header，curl发的 HTTP 请求包会被直接拒收
用反射实现通用 Call 函数时，reflect.Value.Call 的三个易错点
通用 RPC 调用函数看似简单，但反射调用链路上每一步都可能 silently 失败：参数类型不匹配、接收者非指针、返回值没解包。压测时 CPU 火焰图上 runtime.reflectcall 占比飙升，往往就卡在这儿。
- 必须传入指针实例（
reflect.ValueOf(&svc)），否则调用指针接收者方法会 panic - 参数列表要严格按方法签名顺序转成
[]reflect.Value，不能漏掉context.Context（如果方法带 context） - 返回值数组里最后一个一定是
error，但它的Interface()可能是nil，别直接fmt.Println(result[1])——要先result[1].IsNil()
protobuf 替代 gob 后，反射开销没降反升？检查你的 .proto 定义
切到 protobuf 并不自动等于零反射。如果你用 google.golang.org/protobuf 但还在运行时调用 protojson.Marshal 或 prototext.Marshal，这些函数内部仍走反射路径。真正规避反射的是 proto.Marshal（对生成的 struct），但它要求你用 .proto 文件生成代码，且字段定义不能太“松”。
立即学习“go语言免费学习笔记（深入）”；
- 禁止在
.proto里滥用oneof嵌套或map<string, bytes>，这会让生成代码引入额外反射分支 - 所有 message 字段尽量用基本类型或明确的子 message，避免
google.protobuf.Any——它强制 runtime type lookup - 如果必须动态处理未知类型，用
protoreflect.MethodDescriptor查方法，而不是reflect.TypeOf(svc).MethodByName
proto.marshal 调用栈里有没有 reflect.Value.Interface ——有，说明你还在用错 API。 
