用jsoniter替代encoding/json可零改动提速2–5倍，因其绕过反射、预编译缓存并支持零拷贝解析；需改import、加ConfigCompatibleWithStandardLibrary对齐行为，并避免interface{}和冗余字段。
直接换掉 json.Unmarshal，它在高频场景下就是性能黑洞——不是写法错，是底层反射和内存分配模式决定了它扛不住每秒上千次解析。
用 jsoniter 替代 encoding/json，零改动提速 2–5 倍
标准库 json.Unmarshal 每次都走反射路径，字段越多、嵌套越深，开销越大；jsoniter 在保持 API 完全兼容的前提下，用 unsafe 和预编译反射缓存绕过了大部分 runtime 开销。
- 只需改 import：
import json "github.com/json-iterator/go"，其余调用（json.Unmarshal、json.Marshal）完全不用动 - 对数字、字符串、扁平结构体提升最明显；若用了
json.RawMessage或自定义UnmarshalJSON，需跑一遍单元测试验证行为一致性 - 加一句
jsoniter.ConfigCompatibleWithStandardLibrary可进一步对齐错误码和空值处理逻辑，降低迁移风险
结构体字段加 json:"-" 显式忽略无用字段
哪怕只多解析一个没用的 string 字段，也会触发一次堆分配 + GC 压力；尤其在日志、监控等高频小对象场景中，这点开销会被放大数十倍。
- 把确定不读取的字段标为
json:"-"，jsoniter和标准库都会跳过该字段的反射查找和赋值 -
omitempty只影响序列化，反序列化时仍会分配内存，不能替代- - 嵌套结构体里也要逐层加，比如
Meta struct { DebugInfo string `json:"-"` }
复用 json.Decoder 实例 + 预分配缓冲区
高频解析 ≠ 高频新建 json.Decoder；每次 new 都带 bufio.Reader 初始化和状态重置，纯属浪费。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Pool缓存*json.Decoder，但每次Get后必须重置：调用decoder.DisallowUnknownFields()和decoder.UseNumber()（如果需要） - 传入的
io.Reader必须是可重用的，比如bytes.NewReader(data)；别传http.Response.Body这类一次性流 - 给
bufio.NewReaderSize(r, 4096)显式设缓冲大小，避免默认 4KB 不够导致频繁系统调用
别让 interface{} 和 map[string]interface{} 出现在热路径
它们不是“灵活”，是主动放弃编译期类型信息，强制走最慢的动态解析路径——每次字段访问都要做类型断言、堆分配 map 节点、递归构建嵌套结构。
- 哪怕只取两个字段，也定义最小结构体：
type EventKey struct { ID string `json:"id"` Type string `json:"type"` } - 真要支持部分字段动态，用
json.RawMessage接整段字节，后续按需解析，避免提前展开 - 日志类场景中，
time.Time字段直接打 tag：At time.Time `json:"at"`，省去字符串转 time 的额外调用
最容易被忽略的是：高频解析的瓶颈往往不在 JSON 层本身，而在上层反复 make([]byte, len) 或 strings.NewReader ——这些分配比解析还贵。先用 pprof 看清楚 allocs 分布，再决定动哪一层。
