夜雨聆风
json.Marshal 逃逸分析:源码热点路径大起底(第25篇)
大家好，我是kofer，今天继续我们的Go源码深度剖析系列。
在实际业务中，json.Marshal 几乎是每个Go后端服务最热的路径之一。
动不动就占到10%~30%的CPU，甚至更高。
而其中最容易被忽略、也最容易产生“隐形GC压力”的，就是逃逸分析导致的堆分配。
今天我们就从encoding/json的源码（以go1.24 ~ go1.25时期为主）出发，带大家真正看清json.Marshal这条热点路径上，哪些变量逃逸了？为什么逃逸？能优化到什么程度？
一、json.Marshal 的整体调用链（简化版）
json.Marshal(v any) ([]byte, error)
↓
encoder.Encode(v) // *encodeState.Encode()
↓
e.reflectValue(value) // 反射遍历结构体、切片、map...
↓
appendString / writeString / ... // 字符串处理热点
↓
e.Buffer.Bytes() // 最终输出
真正耗时的部分主要集中在反射 + 字符串处理两块。
而逃逸分析最关心的，正是哪些对象因为要被append、要被interface{}持有、要被闭包捕获而逃逸到堆上。
二、三大逃逸重灾区（基于源码实测）
我们用-gcflags=-m编译一个典型的使用场景，来看最常见的逃逸点（以下基于go1.24/1.25主线版本）：
1. encodeState 本身几乎必逃逸
type encodeState struct {
bytes.Buffer
// ... 很多字段
escapeHTML bool
// ...
}
几乎所有json.Marshal调用都会创建一个encodeState，然后往里面写数据，最后Bytes()返回。
但因为：
-
bytes.Buffer 内部的buf []byte 会动态grow -
encodeState 被传给很多方法（指针接收者） -
最终要返回[]byte，而这个[]byte是从Buffer中切出来的
→ encodeState 结构体本身 + 它内部的buf 几乎100%逃逸到堆。
这是最贵的一块逃逸：一次Marshal ≈ 至少1个中等偏大的对象分配。
2. 反射路径下的 interface{} 和 reflect.Value 逃逸地狱
当遇到结构体时：
case reflect.Struct:
// ...
for i := 0; i < t.NumField(); i++ {
f := t.Field(i)
// ...
e.marshalValue(v.Field(i)) // 这里 v.Field(i) 返回 reflect.Value
}
reflect.Value 是一个结构体，里面包含指向原始值的指针。
只要这个reflect.Value 被当作参数传下去、或者被闭包捕获，它里面的指针就会导致原始值逃逸。
最典型的就是自定义MarshalJSON：
func(t Time)MarshalJSON()([]byte, error) {
// t 本身逃逸，因为要取地址给方法接收者
b := make([]byte, 0, 32)
// ...
return b, nil
}
→ 只要结构体实现了MarshalJSON接口，该结构体实例几乎必定逃逸（因为要构造interface{Marshaler}）。
3. 字符串逃逸分析 —— appendString 是性能杀手
这是最容易被优化的部分，也是最容易被忽略的部分。
看核心函数（简化）：
// encode.go
func(e *encodeState)string(s string, quoted bool) {
// ...
start := i
for i < len(s) {
c := s[i]
if c < 0x20 || (quoted && (c == '"' || c == '\\')) || ... {
// 需要转义 → 拷贝前面部分 + 写入转义
if start < i {
e.Write(s[start:i]) // 这里 []byte(s[start:i]) 逃逸！
}
// ...
}
}
// ...
}
关键点：
-
只要字符串中有一个字符需要转义（\n、\t、”、<、>、&、中文高字节等），就会触发路径拷贝 -
e.Write(s[start:i])→ s[start:i] 做string转[]byte → 这段子串逃逸！ -
如果字符串很长且分散有多个转义点 → 产生大量小对象逃逸
实测结论（go1.24+）：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
结论：字符串里转义字符越多，逃逸越严重，小对象爆炸。
三、真实业务场景的逃逸画像（举例）
场景1：日志系统批量Marshal结构体（含time.Time、错误信息）
-
time.Time.MarshalJSON → 强制分配[]byte -
错误字符串通常含\n → 产生多个子串逃逸 -
→ 单次日志 ≈ 8~15次分配，GC压力明显
场景2：对外HTTP接口返回大JSON（含中文描述、富文本）
-
中文UTF-8本身不转义，但只要有少量”&”或”<” → 分段拷贝 -
→ 产生几十个小[]byte对象
场景3：高QPS场景下对象复用池失效
很多人尝试用sync.Pool复用[]byte，但因为encodeState逃逸，池化效果大打折扣。
四、优化方向总结（2025~2026视角）
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目前（2026年初）性价比最高的两条路：
-
直接上代码生成库（sonic目前最激进，逃逸最少） -
业务上能避免的就避免自定义MarshalJSON，这是性价比最高的“无代码优化”
最后
json.Marshal 不是“写得不好”，而是通用性与性能的必然取舍。
但只要我们理解了逃逸分析的每一个关键点，就能在合适的场景下，把它从“热点”变成“可控热点”。
（完）
欢迎关注 kofer X，我们下篇不见不散！
