Go标准库encoding/json在高频、大数据量场景下性能瓶颈源于反射开销、字符串拼接、接口动态判断和频繁内存分配；推荐优先使用jsoniter替代，或对关键结构体启用easyjson代码生成以消除反射。
Go 标准库 encoding/json 默认性能不差，但高频、大数据量或低延迟场景下，它容易成为瓶颈——主要卡在反射开销、字符串拼接、接口类型动态判断和内存分配上。
为什么 json.Marshal 会慢？
核心问题不是算法本身，而是运行时行为：
-
json.Marshal对任意interface{}做反射遍历，每次字段访问都触发reflect.Value.FieldByName，开销显著 - 结构体字段名需反复查表（
structField.name→ 字符串 → JSON key），且默认用map[string]interface{}时完全无类型信息 - 每个字符串 key 和 value 都新分配内存，小对象也触发 GC 压力
- 不支持复用底层
[]byte缓冲区，每次调用都make([]byte, 0, approx)
用 jsoniter 替换标准库（最简单见效方案）
jsoniter 是兼容 encoding/json API 的高性能替代品，通过代码生成 + 更激进的内联 + 零分配优化路径提升性能。实测对中等结构体（10–50 字段）序列化快 2–5 倍。
只需替换导入并保持用法不变：
立即学习“go语言免费学习笔记（深入）”；
import "github.com/json-iterator/go" var json = jsoniter.ConfigCompatibleWithStandardLibrary // 用法完全一致 data, err := json.Marshal(obj)
注意两点：
- 避免混用
encoding/json和jsoniter的 tag（如json:"name,omitempty"兼容，但自定义 marshaler 可能行为不同） - 若项目已用
go:generate生成easyjson，不要盲目切换——easyjson编译期生成代码，通常比jsoniter运行时优化更快，但侵入性强
为高频结构体启用 easyjson 代码生成
当某个结构体被反复序列化（如 API 响应主体、日志事件），用 easyjson 生成专用 marshal/unmarshal 函数，彻底绕过反射。
步骤极简：
- 加注释：
//easyjson:json放在结构体上方 - 运行：
easyjson -all your_file.go - 调用生成的
MarshalJSON()方法而非json.Marshal()
生成代码直接操作字段指针，无反射、无 interface{}、无 map 查找。典型提升：3–10 倍，且 GC 分配接近零。
限制：只支持导出字段；嵌套结构体需各自打标记；不支持匿名字段的深层展开（需显式命名）。
手动控制缓冲区与复用 bytes.Buffer
标准库不提供缓冲区复用接口，但你可以封装一层：
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
func MarshalFast(v interface{}) ([]byte, error) {
b := bufPool.Get().(*bytes.Buffer)
b.Reset()
defer bufPool.Put(b)
err := json.NewEncoder(b).Encode(v)
if err != nil {
return nil, err
}
// Encode 加了换行，若不需要可截掉最后一字节
return b.Bytes(), nil
}
这招对小对象效果有限（因 Encoder 内部仍会分配 token buffer），但对大结构体 + 高并发场景，能减少 10–20% GC 压力。真正关键点是：别在循环里反复 make([]byte, 0)。
最容易被忽略的是字段 tag 的细节：json:"name,string" 会让整数/布尔转成字符串，触发额外格式化；json:",omitempty" 在运行时要判断零值，对指针或接口类型代价更高——高频结构体里，宁可预处理字段，也不要依赖这个 tag。
