gjson.get适合快速提取json中少量字段，性能高（约200ns、零分配）、语法简洁，但仅适用于只读场景，不校验json合法性、不自动类型转换，需配合gjson.valid和exists等方法确保安全。
直接用 gjson.Get 解析未知结构的 JSON 是可行的，但不是万能解药——它适合读取，不适合写入；适合单次提取，不适合反复遍历；更关键的是，它不校验 JSON 合法性，也不帮你做类型转换，全靠你手动判断。
什么时候该用 gjson 而不是 json.Unmarshal
当你只需要从一段 JSON 中快速捞出几个字段，且不关心整体结构是否合法、字段是否存在、类型是否匹配时，gjson 就是最佳选择。比如处理第三方 Webhook、日志上报、配置片段、API 响应中的兜底字段提取。
- 输入 JSON 可能缺失某些 key，或字段类型在不同版本间变化（如
"count"有时是int，有时是"0"字符串） - 你只关心
"data.items.0.name"和"meta.status"这两个路径，其余字段完全忽略 - 性能敏感场景：基准测试显示
gjson.Get平均耗时约200ns，零内存分配，远快于先json.Unmarshal成map[string]interface{}再层层断言 - 你不需要修改原始 JSON，只读场景
别跳过 gjson.Valid，否则 panic 会来得猝不及防
gjson.Get 对非法 JSON 不报错，而是返回空结果；如果你直接调 .String() 或 .Int()，它不会 panic，但可能返回零值（比如 0 或空字符串），而你以为是业务数据。真正危险的是后续逻辑基于这个“假成功”继续执行。
- 务必在调
gjson.Get前加校验：if !gjson.Valid(jsonBytes) { /* 拒绝或记录 */ } - 优先用
gjson.GetBytes处理[]byte，避免重复string转换开销 - 判断字段是否存在，用
result.Exists()，而不是result.String() != ""——因为""是合法 JSON 字符串值 - 如果字段预期为数字但可能传字符串（如
"123"），别硬调.Int()，先用.Raw拿到原始片段再自己解析，或统一走.String()+strconv.Atoi
嵌套数组和通配符的坑：# 和 * 别混用
路径语法里 # 表示数组长度或索引访问，* 是通配符匹配任意 key，二者语义完全不同，混用会导致行为不可预测。
-
data.items.#→ 返回数组长度（int类型） -
data.items.*.name→ 匹配items下所有对象的name字段，返回多个结果（.Array()获取切片） -
data.items.0.name→ 明确取第一个元素的name，安全但不够灵活 - 错误写法：
data.items.#.name会被解释成 “取第#个元素的 name”，而#不是数字，结果为空 - 条件查询要加括号：
friends.#(age > 20).name，漏掉括号会解析失败
和 json.RawMessage 协同使用才是完整方案
gjson 解决的是“快速读”，json.RawMessage 解决的是“延迟定型”。真实后端中，二者常组合使用：外层用 gjson 快速探路，发现某个字段结构复杂或需多次访问时，再用 json.RawMessage 暂存并按需反序列化。
- 例如 Webhook body 中
"payload"字段结构多变，先用gjson.Get(json, "payload").Raw拿到字节，再根据"type"字段决定用哪个 struct 解析 - 避免把
gjson.Result长期持有或塞进 map —— 它内部引用原始字节，可能导致大 JSON 内存无法释放 - 不要试图用
gjson构建通用“JSON to struct” 工具函数：它不提供字段映射、默认值填充、嵌套结构体绑定等能力，那是mapstructure或自定义UnmarshalJSON的事
真正麻烦的从来不是怎么拿到值，而是怎么确定那个值“真的就是你要的”——类型、存在性、上下文一致性，这些都得靠你用 Exists()、Type()、Raw 和业务规则一起守住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
