默认 json.Marshal 性能差因反射开销大、JSON 体积大解析慢；微服务通信应优先选 gRPC+Protobuf，次选 jsoniter 优化 JSON，gob 仅限同构 Go 内部使用，手写序列化易出错。
为什么默认的 json.Marshal 在微服务间传输时会拖慢性能
Go 的 json.Marshal 默认使用反射，字段名需反复查找、类型检查开销大，且生成的 JSON 是文本格式，体积大、解析慢。微服务高频调用下，CPU 和网络带宽容易成为瓶颈。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 避免在 RPC 响应体中直接用
json.Marshal序列化结构体，尤其含嵌套 map/slice 或指针字段时 - 若必须用 JSON，提前用
jsoniter.ConfigCompatibleWithStandardLibrary替代标准库，可提升 30%+ 编解码速度 - 生产环境微服务间通信，优先考虑二进制协议，而非优化 JSON
gRPC + Protocol Buffers 是当前最稳的组合
gRPC 强制使用 Protobuf（.proto 定义），天然支持多语言、向后兼容、体积小、解析快。Go 生态中 google.golang.org/grpc 和 google.golang.org/protobuf 已深度集成。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义消息时避免
map<string string></string>这类弱类型字段，改用明确的repeated KeyValue pairs结构，便于后续字段扩展和校验 - 启用
protoc-gen-go-grpc的UseCustomCodec选项可插拔替换底层编解码器（如换成simdjson-go兼容层，但极少需要） - 注意
oneof字段在 Go 中生成的是 interface{} 类型，反序列化后需显式 type assert，否则易 panic
想零依赖轻量通信？gob 可用但有严重限制
gob 是 Go 原生二进制序列化，无需 IDL，结构体直传，性能接近 Protobuf。但它仅限 Go 语言之间通信，且版本兼容性差：一旦结构体字段增删或类型变更，旧服务反序列化会失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只用于同构内部组件（如 sidecar 与主进程），绝不可用于跨语言或长期演进的服务间接口
- 必须导出所有字段（首字母大写），且不能含未导出嵌套结构（如
type A struct{ b unexported }会导致 panic） - 启动时用
gob.Register()预注册所有可能传输的类型，否则遇到未注册类型会静默失败或 panic
自定义序列化器要注意的三个硬坑
有人为追求极致性能手写二进制序列化（如按字段顺序 writeUint64/writeString），但这极易引入隐性错误。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 字段顺序必须与反序列化端严格一致，Go 的
struct{A,B,C}和struct{C,A,B}是两个不同协议 —— 没有字段名保护 - 忽略
json:",omitempty"这类 tag，自定义序列化器不读取 struct tag，需手动判断零值跳过 - 时间字段统一用
UnixMilli()存 int64，别传time.Time——后者底层包含 location 指针，跨进程无法还原
协议选型不是越快越好，而是看团队维护成本和演化韧性。Protobuf 的 .proto 文件即契约，比任何文档都可靠；而手写序列化器，往往在第一次字段变更时就暴露问题。
