根本原因是json.Marshal每次调用都执行完整反射路径并分配新[]byte，不缓存类型信息；pprof显示reflect.Value.Interface和encoding/json.(*encodeState).marshal占CPU超40%，runtime.mallocgc耗时陡增且GC pause密集。
json.Marshal 为什么在高并发下 CPU 和 GC 同时飙升
根本原因不是你写法错，而是标准库每次调用都走完整反射路径 + 每次分配新 []byte。结构体字段再多、嵌套再深，它都不会缓存类型信息；哪怕同一结构体被序列化 10 万次，json.Marshal 仍会重复解析 tag、遍历字段、检查接口实现。
常见现象：pprof 显示 reflect.Value.Interface 和 encoding/json.(*encodeState).marshal 占 CPU 超 40%；go tool trace 里看到密集的 “GC pause” 竖线，且 runtime.mallocgc 耗时陡增。
- 避免在 hot path 上对
map[string]interface{}调用json.Marshal——它强制走最慢的通用编码路径 - 别传
interface{}或any进去，哪怕底层是 struct，也会触发反射 fallback - 字段名固定、类型稳定时，用导出 struct 替代动态 map，编译期可确定的访问比运行时反射快 3–5 倍
sync.Pool 缓存 *bytes.Buffer 能省多少 GC
直接缓存 *bytes.Buffer 是性价比最高的轻量优化：它不带状态、生命周期可控、复用后能砍掉 60%+ 的小对象分配。但前提是单次序列化输出长度波动不大（比如固定结构的 API 响应），否则频繁 Grow 仍会触发扩容。
别缓存 json.RawMessage 或用户传入的 struct 指针——Pool 会意外延长其存活时间，导致内存无法及时回收。
- 声明全局池：
var bufferPool = sync.Pool{New: func() any { return &bytes.Buffer{} }} - 使用时：
b := bufferPool.Get().(*bytes.Buffer); b.Reset(); json.NewEncoder(b).Encode(v); data := b.Bytes(); bufferPool.Put(b) - 切记调用
b.Reset()，否则下次拿到的是脏缓冲区，可能混入前一次残留数据
sonic 替换标准库前必须确认的三件事
sonic 不是“导入就变快”的魔法库，配置错反而比标准库还慢。它依赖 CGO 和底层 C++ 实现，部署环境稍有偏差就会退化为纯 Go 模式（性能打七折）。
- 构建环境必须允许 CGO：Docker 镜像需含
gcc和libc-dev；Alpine 用户得切到cgruntime或改用sonic-go - 浮点数精度默认不保：
1.0000000000000001可能被序列化为1，业务强依赖时得显式加sonic.UseFloat64Precision() -
nil *struct{}行为不兼容：标准库输出null，sonic 默认 panic，得提前判空或配sonic.Config{NoNullSliceOrMap: true}
流式写入大文件时，为什么 json.Marshal + bufio.Writer 更慢
这不是缓冲区没用好，而是做了两次拷贝：一次 json.Marshal 分配新 []byte，一次 bufio.Writer.Write 把该切片复制进内部缓冲区。更糟的是，Marshal 返回切片的 cap 常远大于 len，导致 Writer 提前 flush（比如你设了 1MB 缓冲，但每次只写 2KB，却因底层数组 cap=4MB 触发扩容逻辑）。
- 正确做法：用
json.NewEncoder(w io.Writer)直接绑定bufio.Writer，让序列化结果零拷贝写入 -
bufio.NewWriterSize(f, 1—— 大文件别用默认 4KB 缓冲，syscall 次数会翻倍10241024) - 确保
w未被其他 goroutine 并发写入，bufio.Writer本身非并发安全
最容易被忽略的点：所有优化都建立在「结构体定义稳定」前提下。如果 DTO 层大量用 map[string]interface{} 或泛型接收任意结构，再好的池、再快的库也救不了反射开销。先收口数据契约，再谈性能。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
