Go 标准库的 encoding/xml 和 encoding/json 不支持访问者模式，需用 xml.Decoder.Token() 流式解析 XML 或 json.RawMessage 延迟解析 JSON，或选用 gjson/xmlquery 等第三方库实现类似功能。
Go 的 encoding/xml 和 encoding/json 不支持访问者模式
Go 标准库的 xml.Unmarshal 和 json.Unmarshal 是“全量解析 + 结构体映射”模型，没有类似 Java DOM 或 Python lxml 那样的树遍历接口，更不存在 Visit、Accept 这类访问者方法。想靠标准库直接实现访问者模式遍历节点，行不通。
常见错误现象：xml.Unmarshal 返回 nil 但字段没被赋值；或 JSON 嵌套太深时手动写结构体爆炸式增长；有人试图用反射递归遍历 interface{}，结果遇到 map[string]interface{} 和 []interface{} 类型断言失败就卡住。
- 真正能“访问任意节点”的路径只有两个：自己构建文档树（如用
xml.Token流式解析），或用第三方库补足抽象层 -
encoding/xml的Decoder.Token()可逐个读取开始/结束标签、字符数据，适合按需跳过、拦截、收集特定路径节点 -
encoding/json没有等价的 Token 接口，必须先解成map[string]interface{}或json.RawMessage，再递归处理——但要注意nil、float64类型误判、循环引用 panic
用 xml.Decoder 手动实现节点访问逻辑
这是最轻量、最可控的方式，适合只关心某几个 XPath 路径（比如 /root/items/item/title）或某类标签（比如所有 <link>）的场景。核心是维护一个深度栈，匹配目标路径时触发回调。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
decoder := xml.NewDecoder(reader)初始化，别用xml.Unmarshal - 每次调用
decoder.Token()得到xml.Token，类型断言为xml.StartElement/xml.EndElement/xml.CharData - 维护一个
path []string切片，遇到StartElement就append标签名，遇到EndElement就path = path[:len(path)-1] - 当
path匹配目标（如len(path) == 3 && path[0] == "root" && path[1] == "items" && path[2] == "title"），且下一个 token 是CharData，就提取文本 - 注意
xml.CharData可能含空白符，用strings.TrimSpace(string(data))清理
JSON 场景下用 json.RawMessage 延迟解析 + 递归访问
对 JSON，标准库不提供流式 Token，但 json.RawMessage 可以把某字段“暂存为字节”，避免提前解码开销。配合递归函数，就能模拟访问者行为。
典型使用场景：API 返回大 JSON，只关心其中 data.items[].metadata.tags，其余字段无需结构体定义。
- 定义顶层结构体，把待访问路径设为
json.RawMessage字段，例如：type Resp struct { Data json.RawMessage `json:"data"` } - 写一个
visitJSON(raw json.RawMessage, path []string, handler func([]byte)) error函数，递归展开 map/array - 进入 map 时检查 key 是否匹配当前
path[0]；进入 array 时对每个元素递归调用，path不变或截断 - 容易踩的坑：
json.Number默认转成float64，但原始 JSON 是整数时可能丢失精度；用UseNumber()解码器设置可保留为字符串 - 性能影响：
json.RawMessage避免了中间结构体分配，但递归深度过大可能栈溢出；生产环境建议加深度限制（如 maxDepth=10）
第三方库选型：推荐 gjson（JSON）和 xmlquery（XML）
如果项目允许引入依赖，这两个库在 Go 生态里最接近“访问者语义”：用字符串路径快速定位节点，不强制建模，返回即用。
gjson 示例：result := gjson.GetBytes(data, "data.items.#.tags.#")，result.ForEach() 就是访问者循环；xmlquery 类似 XPath：nodes, _ := xmlquery.QueryAll(doc, "//item/title")，然后 for _, n := range nodes { fmt.Println(n.InnerText()) }。
-
gjson零内存分配（底层用unsafe直接切片），比json.Unmarshal快 3–5 倍，但只读；修改需换sjson -
xmlquery依赖golang.org/x/net/html，能处理不规范 HTML，但对纯 XML 的命名空间支持弱；若 XML 有xmlns，得手动 strip 前缀或用Find替代QueryAll - 兼容性风险：两个库都不保证 100% 严格遵循 XML/JSON 规范（比如注释、CDATA），生产环境若需完整保真，仍得回退到标准库流式解析
复杂点在于：XML 的命名空间、JSON 的数字精度、任意嵌套层级下的错误恢复——这些不是访问者模式本身的问题，而是你选择的解析路径决定的容错边界。别指望一个通用访问函数能兜住所有 corner case。
