Go JSON序列化性能瓶颈主要源于反射开销、频繁内存分配、类型不确定性及嵌套递归成本；标准库encoding/json为通用性牺牲性能，推荐用json-iterator/go、easyjson等第三方库替代，或通过预生成代码、sync.Pool复用、扁平化结构等方式优化。
Go语言处理复杂结构体序列化时，性能瓶颈主要来自反射开销、内存分配频繁、类型不确定性以及嵌套深度带来的递归成本。标准库 encoding/json 在面对字段多、层级深、含 slice/map/interface{} 的结构体时，效率会明显下降，不是写法问题，而是设计取舍——它优先保障通用性与安全性，而非极致性能。
反射是最大开销来源
标准库对任意结构体做序列化时，需在运行时通过反射获取字段名、类型、标签、可访问性等信息。每次调用 json.Marshal 都触发完整反射路径，尤其当结构体含匿名字段、嵌套指针或 interface{} 时，反射树更庞大。CPU profile 中常看到 reflect.Value.Interface 和 json.typeFields 占比极高。
- 避免将
map[string]interface{}或裸interface{}直接传给json.Marshal，尤其在高频接口中 - 结构体字段必须导出（首字母大写），否则反射无法访问，导致序列化为空对象
- 显式添加
json:"field_name"标签，跳过运行时字段名推导
interface{} 和泛型擦除加剧开销
使用 any、interface{} 接收数据后再转结构体，或在函数参数中过度依赖泛型约束，会让编译器无法在编译期确定具体类型，迫使 JSON 包在运行时反复做类型判断和分支跳转。
- 优先定义明确的 DTO 结构体，而不是用
map[string]any做中间容器 - 若需动态字段，考虑用
json.RawMessage延迟解析，而非全量反序列化到 interface{} - 避免在热路径中做多次类型断言（如
v.(MyStruct)），这本身也带反射成本
内存分配与 GC 压力突出
标准库 json.Marshal 每次都分配新 []byte，深层嵌套结构还会触发多次小对象分配（如临时 map、slice header）。高并发下易引发 GC 频繁，STW 时间上升，P99 延迟毛刺明显。
立即学习“go语言免费学习笔记（深入）”；
- 用
json.Encoder+sync.Pool复用bytes.Buffer，减少堆分配 - 对核心响应结构体，预生成静态序列化代码（如
easyjson），完全消除反射和运行时分配 - 避免结构体中大量使用指针字段（如
*string），增加间接寻址和空值检查成本
嵌套与动态结构放大问题
含多层嵌套 struct、slice of struct、或字段类型依赖运行时判断（如 json.RawMessage 内部再解析）的结构体，会使序列化路径变长且不可预测。标准库无法提前编译优化这类路径。
- 扁平化深层嵌套：把
User.Profile.Address.Street拆为User.Street等直字段（必要时用构造函数维护一致性） - 对固定模式的动态内容，用具体子结构体替代
json.RawMessage，例如定义type Notification struct { Type string; Data AlertData } - 第三方库如
sonic或go-json对嵌套结构有专门优化（SIMD 解析、零拷贝字段提取），实测比标准库快 2–4 倍
