go-micro 不支持多重序列化协议共存，因其初始化时绑定单一编解码器且无运行时切换机制；v3 通过 micro.withcodec() 设置全局 codec，v4 已移除该抽象；推荐方案是拆分服务或使用 grpc 自定义 encoding。
Go-Micro 本身不支持多重序列化协议共存于同一服务实例中——它在初始化时绑定单一编解码器，且不提供运行时切换或多 codec 注册机制。 想靠 go-micro 原生能力实现“一个服务同时用 JSON、Protobuf、MsgPack 处理不同请求”，会掉进设计预期之外的坑里。
为什么 go-micro 的 codec 不支持多协议混用
Go-Micro v3（及更早版本）的 micro.Service 初始化时通过 micro.WithCodec() 设置全局编解码器，该 codec 被用于所有 RPC 请求/响应的序列化。底层 rpc.Client 和 rpc.Server 实例共享同一 codec.Codec 实例，没有按 endpoint、content-type 或 header 动态路由 codec 的逻辑。
- 即使你手动注册多个
codec.NewCodec实例，go-micro不会根据Content-Type或自定义 header 自动选择对应 codec -
go-micro的 transport 层（如 grpc、http）也不透传或解析序列化协议标识，无法触发 codec 分发 - v4（即
github.com/asim/go-micro/v4）已移除内置 codec 抽象，转向依赖底层框架（如 gRPC 的encoding），更不支持此场景
可行替代方案：用 gRPC + 自定义 encoding 实现协议协商
如果你真需要单个服务端支持多种序列化格式（比如兼容老系统 JSON API + 新系统 Protobuf gRPC），应绕过 go-micro 的抽象层，直接使用 gRPC 并接管编码逻辑。gRPC 允许注册多个 encoding.Encoding，并在 grpc.CallOption 或 metadata 中传递协议标识。
- 注册自定义 encoding：
grpc.RegisterEncoding("json", jsonEncoding)、grpc.RegisterEncoding("msgpack", msgpackEncoding) - 客户端调用时指定：
grpc.CallCustomEncoding("json")（需自定义 CallOption） - 服务端从
metadata.MD提取encodingkey，动态选择 decoder/encoder - 注意：gRPC 默认只支持
proto和json（viagrpc-json-proto），msgpack需自行实现encoding.Marshaler和encoding.Unmarshaler
更现实的做法：协议分服务而非分 endpoint
生产环境中，混合序列化协议通常不是靠单服务“支持多种”，而是按协议边界拆分服务或网关路由。这样既避免 runtime 判断开销，也降低调试复杂度。
- 用
gin或echo单独起一个 HTTP/JSON 网关，转发到后端 gRPC 服务（统一用 Protobuf） - 用
grpc-gateway自动生成 REST/JSON 接口，后端仍是纯 Protobuf gRPC - 不同协议走不同 service name：例如
user.json.srvvsuser.pb.srv，由 service mesh（如 Istio）按 host 或 path 路由 - 若必须共用一个 Go 进程，可用
net/http多路复用器监听不同端口：:8080（JSON REST）、:9090（gRPC）、:8081（MsgPack HTTP）
真正麻烦的不是怎么写 codec，而是协议协商发生在哪一层——HTTP header？gRPC metadata？还是 service discovery 标签？选错位置，后续就只能靠 patch 和 wrapper 硬扛。别指望 go-micro 帮你做这个决策。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
