go 的 rpc.codec 接口必须同时实现 readrequestheader 和 writerequestheader，因为 rpc 协议栈严格依赖“头-体”二阶段流程：先通过 header 获取服务名、方法名等元信息，再据此解析 body；缺一则在 server.servecodec 或 client.go 中触发 panic，错误多为 nil pointer dereference 或 invalid memory address。
go 的 rpc.codec 接口必须同时实现 readrequestheader 和 writerequestheader，否则运行时 panic 是必然结果，不是概率问题。
为什么只实现一个方法就 panic
RPC 协议栈在每次调用中严格依赖“头-体”二阶段流程：先调用 ReadRequestHeader 获取服务名、方法名、序列号等元信息，再据此决定如何解析后续的 body；WriteRequestHeader 同理，是写入元信息的必经出口。标准库内部（如 server.ServeCodec 或 client.Go）会无条件调用这两个方法 —— 如果你只实现了其中一个，未实现的那个会返回 nil 指针或未初始化的 error，最终触发 invalid memory address 或 nil pointer dereference。
常见错误现象包括：
- 服务端启动后一收请求就 crash，日志里只有 goroutine stack trace，没具体错误上下文
- 客户端调用
client.Go后立即返回rpc: can't find service，但实际方法已注册 —— 因为 header 没读成功，根本没走到服务查找逻辑
ReadRequestHeader 和 WriteRequestHeader 必须配对设计
这两个方法不是独立工作的，它们共享协议语义。header 字节格式、字段顺序、空值编码方式、字节序，必须完全一致，否则对端无法解析。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
ReadRequestHeader必须从连接中准确读取固定长度或带长度前缀的 header 字节，并反序列化到*rpc.Request；严禁在这里读 body -
WriteRequestHeader写出的 header 必须能被对端的ReadRequestHeader无损还原；比如都用binary.BigEndian.PutUint16写服务名长度，都把ServiceMethod字段按 UTF-8 编码且不带 BOM - 共用的底层
io.ReadWriter（如封装了net.Conn的结构体）必须加锁，否则并发调用时会出现读写错位：A 请求 header 还没读完，B 请求 header 已开始写入，导致数据混杂
如何让 Codec 支持 Protobuf 而不崩
标准 rpc 包不绑定序列化格式，但 body 编解码必须从 header 解析逻辑中剥离，交由 proto.Marshal/proto.Unmarshal 处理。
-
ReadRequestBody的参数body interface{}是一个地址（例如&MyReq{}），不能直接传给proto.Unmarshal；需用reflect.New(reflect.TypeOf(body).Elem().Elem()).Interface()动态构造目标 proto struct 的指针（注意双重Elem()：因为传入的是*T，而T本身是proto.Message） - 别在 Codec 内部硬编码
proto.Register或 proto 文件路径；应由业务层提前注册所有用到的proto.Message类型 - 若需兼容老 JSON 客户端，可在 header 中加
Content-Type字段（如"application/x-protobuf"），并在ReadRequestBody中根据该字段分支处理，但注意字段名要统一、大小写敏感
最容易被忽略的细节：长度前缀与压缩的协同
自定义 Codec 若叠加消息压缩（如 gzip），必须确保压缩作用于完整 length-prefix 消息体之后的所有字节 —— 不是只压 body，也不是压 header + body 而漏掉长度头本身。否则接收方先读 4 字节长度，再按该长度去读，但实际 payload 已被压缩变短，导致 io.ReadFull 阻塞或 EOF 错误。
同样，如果用了分帧（如 4 字节大端长度头），这个长度字段本身绝不能被压缩或加密，否则接收方无法预判后续读取量。线上出问题往往不是编解码逻辑错，而是长度字段和 payload 的边界没对齐。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
