Go的encoding/json默认依赖反射，虽设计合理但高并发下成性能瓶颈；优化需绕过反射，如用go-json编译期生成代码、gjson路径扫描零分配，或easyjson预生成方法。
Go 的 encoding/json 默认就是靠反射干活的——这不是缺陷，是设计取舍；但当你在日志解析、API 网关或高吞吐微服务里频繁调用 json.Unmarshal，反射就成了瓶颈本身。
为什么 json.Unmarshal 一用反射就慢
反射在运行时做三件事：查字段名、读字段值、做类型转换。对每个结构体字段，encoding/json 都要调用 reflect.Value.FieldByName 和 reflect.Value.Interface()，再配一堆空值判断和递归分支。实测中，一个含 20 个字段的结构体，反射开销能占整个 Unmarshal 耗时的 60% 以上。
- 字段未导出（小写首字母）？直接 fallback 到
map[string]interface{}路径，性能雪崩 - 用了
interface{}或嵌套map？每层都触发新反射调用，分配放大数倍 - JSON 字段名和 Go 字段名不一致但没加
json:"xxx"tag？反射还得做字符串匹配，CPU cache 友好度极差
go-json 怎么绕过反射却仍兼容标准库接口
go-json 不是在 runtime 做反射优化，而是靠 go:generate + AST 分析，在编译期为每个结构体生成专用解码函数。比如你定义了 type User struct { ID int `json:"id"` }，它就生成类似 func decodeUser(d *Decoder, v *User) error 的硬编码逻辑，直接按偏移量写内存，跳过所有 reflect 调用。
- 必须用导出字段 + 显式
json:"id"tag，否则生成器找不到绑定目标，退化为反射路径 - 不能有
interface{}字段，因为编译期无法确定运行时类型 - 导入语句必须改成
import json "github.com/goccy/go-json"，否则调不到生成代码 - 对
time.Time这类自定义类型，仍需实现UnmarshalJSON方法，go-json 不会帮你猜格式
gjson.Get 为何完全不碰反射还能快 5–10 倍
gjson.Get 根本不解析 JSON，它只在 []byte 上做指针扫描：找到 "items" 后跳过 {，再找下一个 "0"，定位到 "name" 键后切出对应 value 字节范围。全程无内存分配、无类型构造、不递归下降。
立即学习“go语言免费学习笔记（深入）”；
- 传入
string会隐式转[]byte，高频场景务必用gjson.GetBytes(data, path) -
.String()每次都 new 一个string，若只校验存在性，用.Exists() - 数组索引如
"items.-1.id"越界不 panic，但返回空结果，必须先判.Exists() - 动态 key 场景（如
"200x300"）不能靠路径匹配，得先gjson.Get(..., "image_urls").Map()再遍历
RawMessage 是零拷贝开关，但 buffer 生命周期得自己管
json.RawMessage 就是 []byte 别名，go-json 对它不做任何解析，只是 memcpy 原始字节。但它的数据来自外层解析时的临时 buffer —— 如果你复用 json.Decoder 或用了 sync.Pool，那个 buffer 很可能被下一次调用覆盖。
- 若后续要多次解析同一
RawMessage（比如异步落库 + 实时告警），必须手动 copy：payloadCopy := append([]byte(nil), raw.Payload) - 别直接
fmt.Println(raw)，它不会输出内容，只会打印[123 34 110 97 ...] - 想延迟解析又怕 GC 干扰？把
RawMessage放进结构体字段，配合sync.Pool管理整个结构体实例
真正卡住性能的往往不是“该不该用反射”，而是没意识到：字段是否导出、tag 是否显式、buffer 是否复用、RawMessage 是否裸奔——这些细节在压测时才浮出水面，而线上故障常始于某次忘记加 json:"id" 的提交。
