Go JSON解析优化核心是用json.Decoder流式解码+预定义结构体，避免io.ReadAll和interface{}泛型解码；显式声明JSON标签、复用Decoder实例、慎用嵌套结构体以降低反射与内存开销。
Go 语言中 JSON 解析开销主要来自两方面：一是将整个 JSON 字节流一次性解码为内存结构（如 map[string]interface{} 或结构体），二是频繁的反射调用和字段查找。使用 json.Decoder 的 stream 解码 + 预定义结构体，能显著降低内存分配和反射成本，尤其适合处理大 JSON、流式数据或高并发场景。
用 json.Decoder 替代 json.Unmarshal
json.Unmarshal 要求传入完整字节切片，必须先读完全部内容再解析；而 json.Decoder 可直接包装 io.Reader（如文件、HTTP 响应体、网络连接），边读边解析，避免中间字节拷贝和整块内存占用。
示例：
// ❌ 先读全再解析（可能 OOM） data, _ := io.ReadAll(resp.Body) var user User json.Unmarshal(data, &user) // ✅ 流式解码（内存友好） dec := json.NewDecoder(resp.Body) var user User err := dec.Decode(&user) // 只解析第一个 JSON 值
结构体字段显式声明 JSON 标签
避免反射时动态查找字段名。为结构体字段添加 json:"name" 标签，并确保字段首字母大写（可导出）。Go 的 encoding/json 包在首次解析某结构体类型时会缓存字段映射，后续复用该类型解码时跳过反射开销。
立即学习“go语言免费学习笔记（深入）”；
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
建议写法：
- 字段名与 JSON key 一致时，仍显式写
json:"field_name"，避免隐式行为 - 禁用不需要的字段：用
json:"-"或json:",omitempty"控制序列化，但反序列化时不影响性能 - 避免嵌套过深的结构体，必要时拆分为多个小结构体，提升字段缓存命中率
复用 json.Decoder 实例（谨慎）
json.Decoder 本身不是 goroutine 安全的，但可在单个 goroutine 内复用（例如处理连续的 JSON 行、NDJSON 格式）。调用 dec.Reset(io.Reader) 可重置其内部状态，避免反复创建对象。
适用场景：
- 读取多行 JSON（每行一个对象）的文件或日志流
- 长连接中持续接收 JSON 消息（如 WebSocket）
- 注意：每次
Reset后需确保新 reader 提供合法 JSON，否则错误状态可能残留
避免 interface{} 和 map[string]interface{}
这类泛型解码强制运行时反射遍历所有键值，且生成大量临时接口和 map 对象，GC 压力大。只要 JSON schema 相对稳定，就应优先定义结构体。
若部分字段动态，可组合使用：
- 固定字段用结构体字段
- 动态字段用
json.RawMessage延迟解析（只拷贝原始字节，不解析） - 需要时再对
RawMessage单独解码，按需触发解析
