应使用 Protocol Buffers 替代 JSON，因其二进制编码紧凑、解析快、支持强类型和向后兼容；配合 buffer 复用、避免反射、按需压缩，可显著降低 CPU 和网络开销。
用 Protocol Buffers 替代 JSON
JSON 虽易读易调试，但序列化/反序列化开销大、体积大、无类型约束。gRPC 默认绑定 Protocol Buffers（Protobuf），它二进制编码紧凑、解析快、支持强类型和向后兼容。在微服务通信中，尤其高频小消息场景，切换到 Protobuf 通常能降低 30%~50% 的 CPU 占用和网络传输量。
- 定义
.proto文件，用protoc生成 Go 结构体和 gRPC 接口代码 - 避免在 message 中嵌套过深或使用
any/struct等泛型类型，它们会触发反射，拖慢性能 - 对非 gRPC 场景（如 Kafka 消息），可用
github.com/gogo/protobuf或更现代的google.golang.org/protobuf直接序列化为[]byte
复用序列化缓冲区与对象池
频繁分配 []byte 或结构体指针会增加 GC 压力。尤其在高吞吐消息处理循环中，每次 decode/encode 都 new 一个 buffer 很不划算。
- 用
sync.Pool缓存常用 buffer（如 4KB~32KB 预分配切片），避免反复 malloc - 对 Protobuf message，可实现
Reset()方法重置字段，配合 Pool 复用 struct 实例（注意：需确保无 goroutine 安全隐患） - 示例：
buf := bufPool.Get().([]byte); defer bufPool.Put(buf)，再用proto.Unmarshal(buf[:n], msg)
避免运行时反射序列化
像 encoding/json 或第三方库（如 mapstructure）依赖反射解析字段，在 hot path 上会显著拉低性能。微服务间契约稳定，应尽量静态编译时绑定。
- 禁用
json.Marshal/Unmarshal处理核心业务消息；若必须用 JSON（如对外网关），改用easyjson或ffjson生成静态 marshaler - 不使用
interface{}或map[string]interface{}做消息载体；定义明确的 Protobuf message 或 Go struct - 检查日志、监控埋点等辅助路径是否意外触发了反射序列化（例如 zap 的
Any字段）
压缩高冗余消息体（按需）
不是所有消息都适合压缩。小消息（
立即学习“go语言免费学习笔记（深入）”；
- 优先选
snappy（Go 标准库支持，速度快、压缩比适中），比 gzip 更适合 RPC 场景 - 只在 producer 端压缩、consumer 端解压，避免中间件（如 NATS/Kafka）参与；压缩标记通过 header 或 message wrapper 字段传递
- 设置阈值（如 >2KB）才启用压缩，避免小包浪费 CPU
基本上就这些。关键不在堆技术，而在选对协议、控住分配、避开反射——Golang 的性能优势恰恰体现在可控、可预测的内存和调度行为上。
