jsoniter可零改动提速2–5倍，easyjson生成代码消除反射提升3–8倍，json.RawMessage延迟解析避免冗余，固定结构体替代interface{}降低开销。
Go 标准库的 encoding/json 默认足够可靠，但不是最快的；如果你的接口 30% 时间花在 json.Unmarshal 上，说明它已成瓶颈，该换方案了。
用 jsoniter 替代标准库，零代码改动即可提速 2–5 倍
多数场景下，jsoniter 是最省心的加速方案：API 完全兼容 encoding/json，只需替换 import 路径，无需改结构体或调用逻辑。
- 安装：
go get github.com/json-iterator/go - 替换 import：
import json "github.com/json-iterator/go"（而非"encoding/json"） - 直接使用
json.Unmarshal和json.Marshal，行为一致，但底层用了更激进的 unsafe 和预编译反射缓存 - 注意：若项目用了
json.RawMessage或自定义UnmarshalJSON方法，需验证兼容性；jsoniter对某些边缘 case（如嵌套过深的 interface{}）默认行为略有不同
提前生成结构体解析代码：用 easyjson 消除反射开销
当单次请求需解析成百上千个相同结构体（如日志批量上报、ETL 流水线），反射是最大拖累；easyjson 把 Unmarshal 编译成纯函数调用，完全绕过 reflect。
- 为结构体生成代码：
easyjson -all user.go，会生成user_easyjson.go - 调用时改用
User.UnmarshalJSON(data)，而非json.Unmarshal(data, &u) - 性能提升明显（常达 3–8 倍），但代价是：每次改结构体都要重新生成；不支持匿名字段、
interface{}、动态 key 等运行时特性 - 生成代码体积略大，若二进制 size 敏感（如嵌入式 Go），需权衡
避免反复解析同一份 JSON：用 json.RawMessage 延迟解析
常见模式是先解出顶层字段做路由判断（如 "type": "order"），再按类型解析子结构；若每次都全量解析，浪费严重。
立即学习“go语言免费学习笔记（深入）”；
- 把不确定的子字段声明为
json.RawMessage类型，只在真正需要时才调用json.Unmarshal - 示例：
type Event struct { Type string `json:"type"` Data json.RawMessage `json:"data"` } // 后续按 Type 分支解析 Data，避免无谓解析 - 注意：
json.RawMessage本质是 []byte 切片，不拷贝原始数据，因此必须确保源[]byte生命周期覆盖整个使用过程，否则可能引发 panic 或读到脏数据
警惕 interface{} 和 map[string]interface{} 的隐式开销
这类泛型解析看似灵活，实则强制走最慢路径：每个字段都要动态推导类型、分配内存、构建嵌套 map/slice，GC 压力也显著上升。
- 除非业务真需要动态 schema（如配置中心、低代码引擎），否则应坚定使用具体结构体
- 若必须用
map[string]interface{}，至少预估 key 集合并用make(map[string]interface{}, N)初始化容量，减少扩容次数 -
jsoniter.ConfigCompatibleWithStandardLibrary下的interface{}解析比标准库略快，但仍是性能黑洞，别把它当默认选项
真正影响 JSON 解析速度的，往往不是算法本身，而是你是否让 Go 知道“这个结构永远长这样”——越早放弃通用性，越容易拿到确定性性能。生成代码、延迟解析、固定类型，三者选其二，通常就能砍掉 70% 的解析耗时。
