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 倍。

只需替换导入并保持用法不变：

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。