go语言反射不直接参与rpc通信，仅被net/rpc等框架内部用于服务注册、方法查找和参数编解码；需满足导出方法、正确签名及字段导出等约束，否则调用时panic或静默失败。
Go语言反射本身不直接参与RPC通信，它只是在net/rpc或gRPC等框架内部被用来实现服务注册、方法查找和参数编解码——你不需要手动调用reflect.Value.Call去发起远程调用。
为什么RPC框架内部要用reflect
RPC服务端需要根据客户端传来的函数名和参数，动态匹配并执行本地已注册的导出方法。这个“名字→函数→调用”的过程无法靠静态代码完成，必须依赖反射：
-
net/rpc在server.register时遍历结构体所有导出方法，用reflect.typeof提取方法签名，存入serviceMap - 收到请求后，用
reflect.Value.MethodByName查到对应方法，再用reflect.Value.Call执行，把结果序列化回传 - 参数和返回值的序列化（如
gob）也依赖reflect读取字段值，尤其对嵌套结构、接口类型、指针等
net/rpc中反射相关的典型错误
这些不是网络问题，而是反射层面的约束没满足，导致注册失败或调用 panic：
- 方法名未导出（首字母小写），
reflect.Value.MethodByName返回空Value，调用时报panic: call of zero Value.Call - 方法签名不符合
func(*T, *Args, *Reply) Error格式，注册时server.Register会静默跳过（无报错但不可调用） -
Args或Reply类型含非导出字段，gob编码失败，客户端收不到响应，日志里只显示rpc: gob server codec error - 传参用了值类型而非指针（如
func(*MyService, Args, *Reply) error），反射调用时参数数量/类型不匹配，直接 panic
gRPC里反射还起作用吗
标准gRPC-Go（google.golang.org/grpc）**不依赖运行时反射做方法分发**——它通过 Protocol Buffer 生成的*_grpc.pb.go文件，把每个 RPC 方法编译为硬编码的函数指针映射（serviceDesc.Methods）。所以：
立即学习“go语言免费学习笔记（深入）”；
- 没有
MethodByName，没有动态查找，性能更高、启动更快 - 但
grpc.ReflectionServer（用于gRPC CLI或服务发现）会用reflect读取生成代码里的fileDescriptor和serviceDesc，属于元数据查询，不参与实际调用路径 - 如果你手写
UnaryInterceptor做通用日志或鉴权，可能用reflect.TypeOf(info.Handler)判断是哪个方法，但这属于上层扩展，非框架必需
package main import ( "log" "net/rpc" )
type Args struct { A, B int }
type Reply struct { C int }
type Arith int
func (t Arith) Multiply(args Args, reply Reply) error { reply.C = args.A args.B return nil }
func main() { arith := new(Arith) rpc.Register(arith) // ← 这里触发 reflect.TypeOf(arith).NumMethod() rpc.HandleHTTP() log.Fatal(rpc.ListenAndServeHTTP("tcp", ":1234")) }
真正要小心的是：反射让 RPC 看似“自动”，但一旦类型不满足约定（比如字段没导出、方法签名错一位），错误往往不报在注册时，而是在第一次调用才 panic 或静默失败。这类问题很难 debug，因为堆栈里全是reflect内部帧。