Go标准库net/rpc默认不支持Header，需自定义扩展：方案一修改消息结构封装Header；方案二利用HTTP层复用Header；方案三升级gRPC原生支持Metadata；均需注意键名冲突、长度限制与敏感信息防护。
Go 语言标准库的 net/rpc 默认不支持自定义 Header 或 Metadata，它只基于简单的编码（如 Gob、JSON）传输请求和响应体。若需在 RPC 调用中传递认证 Token、TraceID、租户 ID 等上下文信息，必须自行扩展协议层。核心思路是：**在序列化前注入元数据，在反序列化后提取元数据，并确保客户端和服务端对格式达成一致。**
方案一：修改 RPC 消息结构（推荐，轻量可控）
不依赖 gRPC，纯用 net/rpc，可通过包装 rpc.Call 和 rpc.ServerCodec 实现。关键是在每个请求/响应体外再套一层带 Header 的结构：
- 定义统一消息格式，例如：
type RPCMessage struct { Header map[string]string `json:"header"` Body interface{} `json:"body"` } - 实现自定义
ClientCodec：在WriteRequest中将原RequestBody封装进RPCMessage.Body，同时把context.Value中的 metadata 写入Header；ReadResponseHeader则先解出RPCMessage，再从Header提取元数据存入本地 context（如通过context.WithValue）。 - 服务端同理，自定义
ServerCodec在ReadRequestHeader解出 Header 并注入 handler 的 context；WriteResponse可选择性返回 Header（如透传 TraceID）。
方案二：利用 HTTP Transport 层（适用于 JSON-RPC over HTTP）
如果 RPC 基于 HTTP（比如用 http.ServeMux 暴露 JSON-RPC 接口），可直接复用 HTTP Header：
- 客户端用
http.Client发起 POST 请求，手动设置X-Auth-Token、X-Trace-ID等 Header； - 服务端在
http.Handler中解析 Header，注入到 RPC 调用的 context 中（例如通过rpc.DefaultServer.RegisterName注册的 handler 包裹一层中间件）； - 注意：标准
jsonrpc2或net/rpc/jsonrpc不解析 HTTP Header，需自己桥接——即不走rpc.ServeHTTP，而是手写 handler 解析 HTTP body + header，再调用server.ServeCodec。
方案三：使用 gRPC（更成熟，但非标准 net/rpc）
若项目允许技术栈升级，gRPC 原生支持 Metadata（即 Header）：
立即学习“go语言免费学习笔记（深入）”；
- 客户端：
ctx = metadata.AppendToOutgoingContext(ctx, "auth", "Bearer xxx", "tenant", "acme")； - 服务端：
md, ok := metadata.FromIncomingContext(ctx)，即可读取所有键值对； - Metadata 自动随请求透传，支持二进制和 ASCII key，也支持拦截器做统一鉴权或日志打点。
注意事项与避坑点
无论哪种方式，都要注意：
- Header 键名避免冲突（如不要用
Content-Type、Connection等 HTTP 保留字段）； - Metadata 值建议限制长度（如单个值 ≤ 4KB），防止序列化膨胀或拒绝服务攻击；
- 敏感信息（如密码、密钥）不应放在 Header 中明文传递，应走 OAuth2/Bearer Token 或签名机制；
- 若用自定义 Codec，务必保证 client/server 使用相同编码（如都用
json.Encoder），且io.ReadCloser/io.WriteCloser生命周期管理正确，否则会卡死或 panic。
基本上就这些。自定义 Header 的本质是“在协议边界上多塞一层上下文”，不复杂但容易忽略序列化一致性与生命周期控制。
