gjson 解析点号路径比手写递归更可靠,因其专为路径查询设计,支持数组索引(如"items.0.name")、条件过滤、特殊字符转义(如"user.email")及嵌套JSON字符串的.Raw安全提取,避免类型断言panic和空值错误。
gjson 解析点号路径比手写递归更可靠Go 原生 encoding/json 不支持点号路径(如 "user.profile.name"),硬写递归解析容易漏掉数组索引、类型断言错误或空值 panic。直接用 gjson 是最省心的选择——它专为这种场景设计,且性能极佳。
常见错误现象:用 json.Unmarshal 解成 map[string]interface{} 后层层 .(map[string]interface{}) 断言,遇到 null 或数组就 panic;或者自己写字符串分割 + for 循环,结果 "items.0.name" 这种带数字索引的路径处理错位。
go get -u github.com/tidwall/gjson
gjson.Get(jsonStr, "user.profile.name") 直接返回 gjson.Result,调用 .String() / .Int() / .Exists() 安全取值"items.0.name"、"items.#.id"(匹配所有 id)、"items.#(type=="admin").name"(条件过滤).# 或明确下标JSON 中数组字段不能直接用 "list.0.item" 这种写法——gjson 要求索引前加 .,但 0 是合法 key 名,所以 "list.0.item" 实际查的是 list 对象下 key 为 "0" 的字段,而非数组第 0 项。这是最容易踩的坑。
"list.0.item" → 错(查 map key);"list.#.item" → 对(遍历所有数组元素);"list.0.item" 加反斜杠转义?不行,gjson 不支持"list.N.item"(N 是整数),且确保 list 确实是数组,否则返回空gjson.Get(json, "list.#").Array() 拿到所有元素,再逐个查子字段,比硬写路径更健壮.Raw 提取再二次解析如果原始 JSON 里某个字段值本身是 JSON 字符串(比如 {"config":"{"timeout":30}"}),直接 gjson.Get(json, "config").String() 取出来的是带转义的字符串,不是结构化数据。这时候不能跳过 .Raw。
立即学习“go语言免费学习笔记(深入)”;
gjson.Get(json, "config").Raw 返回未解析的原始 JSON 字符串(不含外层引号,可直接喂给 json.Unmarshal)json.Unmarshal([]byte(gjson.Get(json, "config").String()), &v) —— 因为 .String() 返回的是带双引号的字符串,如 "{"timeout":30}",导致解析失败sub := gjson.Get(json, "config"); if sub.Exists() { json.Unmarshal([]byte(sub.Raw), &configStruct) }
. 转义当 JSON key 本身含点号(如 {"user.email": "[email protected]"}),直接写 "user.email" 会被 gjson 当作嵌套路径,实际要查的是 key 名为 "user.email" 的字段。这时必须转义。
. 替换原 key 中的 .,即查 "user.email"
"data[0].name" → 应写成 "data[0].name"(注意 gjson 对 [ 和 ] 也需转义)strings.ReplaceAll(key, ".", ".") 预处理点号路径看着简单,但数组索引、嵌套 JSON 字符串、特殊字符转义这三处,任一处没对齐就会静默返回空或 panic。别图省事跳过 .Exists() 检查,也别信“反正数据格式固定”——线上 JSON 结构松动比想象中频繁。
BoxAgnts 工具系统(4)——Tool Trait 和并发上下文模型
老板:“你是怎么使用 AI 的:真能做到不手写代码?为什么 Codex 在我手里感觉是个智障。。”我:“这样:然后再这样。。”老板直接跪了。
Agent 系统的启动流程:自配置到运行时
SpaceMind - 科大讯飞打造的智能空间Agent与场景自动化平台
AI工程师的第一课 - Python
AI Skills 工程化:当每个开发者都有一支AI小队,你该怎么管理?