json.Marshal慢因反射和堆分配，应全局复用jsoniter.Config并预计算字段偏移；绕过全量序列化，用json.RawMessage+gjson提取字段，禁用fmt.Sprintf，HTTP加MaxBytesReader限流。
直接用 json.Marshal 处理大对象，不是慢在“序列化逻辑”，而是每次调用都触发反射 + 频繁堆分配——尤其当结构体字段多、嵌套深、含 time.Time 或 map 时，runtime.mallocgc 会高频上浮，GC pause 拉高 P99 延迟。
为什么 jsoniter.Config{}.Froze() 在 handler 里初始化等于自废武功
每次请求都 new 一个 jsoniter.Config 再 Froze()，等于重做一次反射缓存构建：字段扫描、tag 解析、encoder 注册全来一遍。它比标准库还慢，因为额外多了 config 构建开销。
- 正确做法是全局只初始化一次：
var json = jsoniter.ConfigCompatibleWithStandardLibrary，后续所有json.Marshal共享同一份冻结后的反射元数据 - 若需自定义（如
time.Time输出 Unix 时间戳），注册一次 encoder：json.RegisterExtension(&jsoniter.DurationExtension{})，别塞进 handler - 没设
Unsafe = true时，字符串拼接走的是安全路径，少掉 20–40% 性能；可信数据源（如内部 RPC）可放心开
字段多的 struct，FieldByName 是隐形 CPU 杀手
FieldByName("CreatedAt") 在 50 字段的 struct 上平均要比较 25 次字符串，100 字段就是 50 次——这是纯线性搜索，且每次比对都触发内存分配（字符串临时构造）。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 改用预计算字段索引：
typ := reflect.TypeOf((*MyStruct)(nil)).Elem(); field, _ := typ.FieldByName("CreatedAt"); offset := field.Offset，之后用unsafe.Pointer直接偏移取值 - 缓存 key 必须用
uintptr(unsafe.Pointer(typ))，别用typ.String()或包路径拼接——匿名 struct 会崩，vendoring 多版本下 key 冲突 - 字段级缓存内容建议是
struct { Offset uintptr; IsExported bool; Tag string }，不是裸的[]reflect.StructField
真正省时间的，往往不是优化 Marshal，而是绕过它
很多接口吞吐卡住，根本不是 json.Marshal 慢，而是你在 hot path 上做了三件多余的事：把 interface{} 当参数传、用 fmt.Sprintf 拼日志、对整段 JSON 做无差别 Unmarshal。
立即学习“go语言免费学习笔记（深入）”；
- 对只读部分字段（如 webhook 的
event.type和data.id），用json.RawMessage接收，再用gjson.GetBytes(payload.Data, "items.0.price")零分配提取 - 日志中间件禁用
fmt.Sprintf("req=%v", req)，改用strings.Builder显式拼关键字段：sb.WriteString("id="); sb.WriteString(strconv.Itoa(req.ID)) - HTTP body 未加限流：
http.MaxBytesReader必须设，否则 50MB 恶意 JSON 会让io.ReadAll分配超大 slice 直接逃逸到堆
最易被忽略的一点：结构体字段顺序变更（比如插了个新字段）会让所有基于 unsafe.Offsetof 的偏移缓存失效，但编译器不报错——它只是默默变回反射路径。这类问题只在压测时暴露，且难以复现。
