net/rpc看似对称实则脆弱，因依赖gob编码和严格一致的go结构体定义，版本差异或字段不匹配易致静默失败；而grpc基于protobuf和http/2，跨语言、强类型、支持流式，真正实现高度对称与生产可用。
net/rpc 默认就是高度对称的通信模型，但“快速实现”和“高度对称”常被误解为“两端代码结构一致、编解码自动匹配、无需额外协议定义”。实际上，Go 的 net/rpc 确实提供了这种对称性基础，但生产环境里它极易因细节失控而失效。
为什么 net/rpc 看似对称却容易出错
net/rpc 要求服务端方法签名严格满足 func(*Args, *Reply) error 形式，且 Args 和 Reply 必须在客户端和服务端完全一致（包括字段名、导出性、嵌套结构）。一旦结构体定义不统一（比如一个地方用 type User struct { Name string }，另一处漏了导出或改了字段名），就会静默失败或 panic。
更隐蔽的问题是：它默认用 gob 编码，而 gob 依赖 Go 类型的运行时反射信息。如果服务端和客户端 Go 版本差异较大（如 1.20 vs 1.22），或结构体字段顺序/标签有微小变动，gob 解码可能直接崩溃，错误信息常是 unexpected EOF 或 invalid type，不指向具体字段。
net/rpc 对称通信的最小可行配置
要真正“快速跑通”，必须锁定以下三点：
- 所有共享结构体定义放在独立包（如
shared）中，由服务端和客户端共同 import，禁止复制粘贴 - 服务端注册时用
rpc.RegisterName("MyService", service)显式命名，避免默认包名干扰 - 客户端调用前务必检查
client.Call("MyService.MethodName", args, reply)返回的error—— 即使reply有值，也可能只是部分解码成功 - 连接建立后立即用
client.Ping()（可自定义一个空方法）验证通道可用性，而不是等到首次业务调用才暴露网络问题
何时该放弃 net/rpc 改用 gRPC
当出现以下任一情况，说明你已超出 net/rpc 的对称舒适区：
- 需要跨语言通信（Java/Python 客户端）——
gob是 Go 专属，net/rpc不支持其他编码器 - 想自动校验接口契约（比如参数必填、字段长度限制）——
net/rpc无 schema，全靠人肉对齐 - 服务要支持流式响应或双向流 ——
net/rpc只支持单次请求-响应 - 已有
.proto文件，或团队已统一使用 Protobuf —— 强行迁移到net/rpc反而破坏对称性
此时用 protoc 生成 Go 代码，服务端和客户端天然共享同一份类型定义，gRPC 的 Call 和 Invoke 接口签名也完全镜像，才是真正的“高度对称”。
加密层叠加不影响对称性，但会掩盖底层问题
有人试图在 net/rpc 上套 TLS 或 AES-GCM 加密，以为能提升安全性。但要注意：net/rpc 的 Client 和 Server 都不感知加密，你得自己包装 net.Conn。一旦加解密逻辑在两端不严格一致（比如 IV 复用、padding 方式不同），就会导致 gob 解码失败，错误仍表现为 “invalid encoding”，排查时容易误判为 RPC 层问题。
真正安全又保持对称的做法是：先用 gRPC + TLS，再对敏感字段单独 AES 加密（如用户身份证号），这样传输层和应用层职责分离，出问题能快速定位到哪一层。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
