不能直接用 xml.Unmarshal 解大文件，因为它会将整个 XML 加载进内存解析，导致内存激增、GC 压力大或 OOM；应使用 encoding/xml.Decoder 流式读取，逐 token 处理，手动维护状态并累积 CharData 内容。
为什么不能直接用 xml.Unmarshal 解大文件
因为 xml.Unmarshal 会把整个 XML 加载进内存再解析，100MB 的文件可能吃掉 500MB+ 内存，还容易触发 GC 压力或 OOM。真正处理大文件（比如 GB 级日志、导出数据）必须流式读取——encoding/xml.Decoder 就是干这个的，它不缓存整棵树，只按需推进 token。
如何用 Decoder.Token() 逐节点读取
核心是循环调用 decoder.Token()，每次返回一个 xml.Token：可能是 xml.StartElement、xml.EndElement、xml.CharData 或 xml.Comment。你得自己维护状态（比如当前路径、是否在目标标签内），而不是依赖结构体绑定。
- 用
decoder := xml.NewDecoder(reader)初始化，reader可以是os.File或bytes.Reader - 跳过无关 token：遇到
xml.Directive或空格类xml.CharData（长度为 0 或全是空白）可直接 continue - 区分开始/结束标签：
t, ok := token.(xml.StartElement)和t, ok := token.(xml.EndElement)是常见类型断言 - 注意命名空间：如果 XML 有
xmlns，StartElement.Name.Space可能非空，匹配标签名时要一起比较
怎么安全提取嵌套结构里的文本内容
别在 xml.CharData 里直接赋值——它可能被多次触发（换行、缩进、CDATA 分段都会产生多个 CharData）。正确做法是累积到 buffer，等遇到对应 xml.EndElement 再处理。
var content strings.Builder
inTargetTag := false
for {
token, err := decoder.Token()
if err == io.EOF {
break
}
if err != nil {
log.Fatal(err)
}
switch t := token.(type) {
case xml.StartElement:
if t.Name.Local == "item" && t.Name.Space == "" {
inTargetTag = true
}
case xml.CharData:
if inTargetTag {
content.Write(t) // 注意：t 是 []byte，不是 string
}
case xml.EndElement:
if t.Name.Local == "item" {
fmt.Println("content:", strings.TrimSpace(content.String()))
content.Reset()
inTargetTag = false
}
}
}
容易忽略的边界问题和性能陷阱
Decoder 默认会自动处理 UTF-16/UTF-32 BOM，但如果你的 XML 声明是 <?xml version="1.0" encoding="GB2312"?>，Go 标准库不支持 GBK/GB2312，会报 invalid character entity 错误——必须先用 golang.org/x/text/encoding 转成 UTF-8 再交给 Decoder。
- 不要在循环里反复 new struct 然后
decoder.DecodeElement(&v, &start)：虽然方便，但每次反射开销大，且仍会临时分配字段字符串 - 避免用
decoder.Skip()跳过深层嵌套：它内部仍会递归读 token，不如手动 while 循环 + 计数器更可控 - XML 中的属性值不会自动 decode HTML 实体（如
&），需要自己调用html.UnescapeString(string(attr.Value))
真正难的不是读 token，而是状态机设计：什么时候开始采集、什么时候提交、怎么处理同名嵌套标签、怎么应对缺失闭合标签。这些逻辑没标准答案，得贴着你的 XML Schema 去写。
