根本问题是内存分配而非序列化算法，需用sync.Pool复用*MyMsg指针并调Reset()，预分配缓冲区，关闭Deterministic，改用.google.protobuf.Timestamp和optional字段，绕过反射选用go-json。
proto.Marshal耗时飙升、GC频繁怎么办
根本问题不是序列化逻辑写得不好，而是每次调用都在堆上分配新 slice 和 map。pprof 显示 mallocgc 占比超 60%，说明瓶颈在内存分配，不是编码算法本身。
- 别用
var msg MyMsg; proto.Unmarshal(buf, &msg)—— 这会新建结构体，但底层数组仍 malloc - 改用
sync.Pool管理指针：var msgPool = sync.Pool{New: func() any { return &MyMsg{} }} - 取出来后调
msg.Reset()（Go 1.21+ 标准库支持），比新建快 3–5 倍，且复用底层 buffer - 归还前确保字段已清空，尤其注意未导出字段（如内部缓存）是否影响 Reset 行为
JSON 序列化卡在 encoder.Encode() 不返回
这不是死锁，是反射遍历开销爆炸。字段数 >50 或嵌套 >5 层时，json.Encoder.Encode 会花大量时间做类型检查和字段名哈希查找。
- 放弃
json.Marshal+bytes.Buffer拼接：实测百万条/秒 → 三百万条/秒，靠手写WriteString+WriteByte - 用
go-json替代标准库：它生成静态代码，零反射，兼容encoding/json接口，上线无感切换 - 避免在 hot path 上做
json.RawMessage转换：如果上游已确认是合法 JSON，直接透传[]byte，少一次 decode - 慎用
interface{}字段：反射无法跳过，哪怕只有一处，整条链路性能断崖下跌
并发调用 proto.Marshal 出现延迟毛刺
不是 CPU 不够，是 goroutine 调度排队 + channel 阻塞导致 P99 延迟突增。现象是吞吐量稳定，但个别请求耗时从 2ms 跳到 200ms。
- 别用
for range启动上百 goroutine 直接调proto.Marshal—— 调度器扛不住 - 用带缓冲的 worker channel 控制并发数：
ch := make(chan *pb.Msg, 1000)，固定 4–8 个消费者 goroutine 消费 - 传参别传
*pb.Msg指针进 goroutine：如果该实例还在被其他 goroutine 引用，可能导致意外修改或 GC 延迟 - 关闭
Deterministic选项（除非真需要确定性输出）：map 排序开销能省 10–15%，高频场景值得关
protobuf 编码体积大、Timestamp 序列化慢
默认 protobuf 对 int64 时间戳用 varint 编码，纳秒级时间要拆成 8–10 字节；零值字段也全写进去，浪费带宽和解析时间。
立即学习“go语言免费学习笔记（深入）”；
- 把
int64 timestamp改成.google.protobuf.Timestamp：内部优化了 varint 编码路径，且支持标准语义 JSON 输出 - proto3.12+ 中启用
optional字段：未设置的字段不编码，比omitemptytag 更彻底（后者只影响 JSON） - 预分配缓冲区：用
proto.Size()提前算好长度，再调proto.MarshalTo(buf)，避免 Marshal 内部 realloc - 别混用
gogofaster和标准google.golang.org/protobuf：运行时不兼容，panic 很隐蔽
