gob 不适合跨语言 rpc 通信，因其是 go 专有格式、无稳定跨语言规范、不支持 schema 版本控制、字段变更易导致解码失败，且调试困难；应选用 protobuf 或 msgpack 等多语言支持方案。
为什么 gob 不适合跨语言 RPC 通信
因为 gob 是 Go 专有的二进制序列化格式，没有公开、稳定的跨语言规范，其他语言几乎无法可靠解析。哪怕你硬写了个 Python 解码器，Go 一次内部字段重排或类型升级（比如 int 变 int64），就直接 decode 失败。
- Go 1.19+ 对结构体未导出字段的
gob编码行为有细微调整，旧客户端可能 panic -
gob不带 schema 版本控制，服务端加个字段，老客户端反序列化直接报unexpected EOF或静默丢数据 - 调试困难：抓包看到的是一串不可读字节，没法像 JSON/Protobuf 那样快速确认 payload 是否符合预期
真正要自定义协议，序列化层必须选有明确定义、多语言支持、带版本演进能力的方案，比如 protobuf 或 msgpack（后者需自行约定 schema）。
如何在 net.Conn 上安全收发变长 RPC 消息
TCP 是字节流，没有消息边界。直接 conn.Read() 可能只读到半条请求，也可能一次读到两条拼在一起——这是自定义 RPC 最常卡住的地方。
- 必须自己实现消息帧（framing）：推荐在每条消息前加 4 字节大端长度头，用
binary.BigEndian.PutUint32()写，binary.BigEndian.Uint32()读 - 不要用
bufio.Scanner或按行切割，RPC 不是日志；也不要依赖超时来“凑够”一次读取，网络延迟波动会让逻辑不可靠 - 务必处理粘包和拆包：封装一个
readMessage(conn net.Conn) ([]byte, error)，内部循环调用io.ReadFull()先读长度，再读正文
示例关键片段：
var lengthBuf [4]byte<br>if _, err := io.ReadFull(conn, lengthBuf[:]); err != nil {<br> return nil, err<br>}<br>length := binary.BigEndian.Uint32(lengthBuf[:])<br>buf := make([]byte, length)<br>_, err := io.ReadFull(conn, buf)<br>return buf, err
立即学习“go语言免费学习笔记（深入）”；
rpc.Server.Register() 为什么注册不了私有方法
Go 的 rpc 包（包括标准库和多数自定义实现）只暴露首字母大写的导出方法。这不是 bug，是设计约束：反射无法获取私有方法的签名，也无法保证其线程安全或语义清晰。
- 方法名必须以大写字母开头，且接收者必须是指针类型（如
func (s *Service) DoSomething(...)） - 参数和返回值类型必须是导出类型，否则序列化时会报
rpc: method has unexported parameter or return type - 如果用了自定义序列化（比如 protobuf），还要额外确保这些类型已注册到 codec，否则 runtime panic
常见错误现象：rpc: can't find service ServiceName，往往不是名字错了，而是整个 struct 没导出，或者方法签名里混了 map[string]unexportedStruct 这类非法组合。
为什么不用 http.HandlerFunc 直接做 RPC 端点
可以，但容易低估 HTTP 的隐含成本和语义错位。HTTP 是文档传输协议，不是远程过程调用协议。
- 每个请求都带完整 header、status line、body boundary，对高频小请求（比如毫秒级风控校验）带宽和解析开销明显高于裸 TCP 帧
- HTTP/1.1 默认短连接，频繁建连耗 CPU；HTTP/2 虽然复用，但 stream 管理、HPACK 压缩、优先级树全是额外复杂度
- HTTP status code 和 RPC 错误码不等价：比如
503 Service Unavailable是服务端过载，但业务上可能是 “用户余额不足”，强行映射会丢失语义
真要用 HTTP，至少把 body 设为纯二进制（Content-Type: application/octet-stream），跳过所有 JSON/XML 封装，并用 HTTP/2 + keep-alive。但这时你其实已经是在造一个跑在 HTTP 之上的自定义 RPC 协议了。
真正难的不是编解码或网络收发，而是错误传播的一致性：客户端怎么区分是网络超时、服务端 panic、还是业务逻辑拒绝？这个边界一旦模糊，上游就只能不断加重试和降级逻辑。
