xml.decoder是唯一靠谱的高性能流式解析方案，因其边读边解析、内存占用仅几mb；而xml.unmarshal需全量加载xml致oom。
用 xml.Decoder 做流式解析是唯一靠谱的高性能路径，xml.Unmarshal 一上大文件就 OOM，不是调优问题，是设计不匹配。
为什么 xml.Decoder 才算真流式
xml.Unmarshal 必须把整个 XML 加载进内存再解析，100MB 文件实际占用常超 300MB；xml.Decoder 是边读边解析，内存只跟当前节点深度和字段长度相关，稳定在几 MB 级别。这不是“稍微快一点”，而是量级差异。
- 适用场景：日志归档、报表导出、HTTP Body 流、gzip 压缩 XML（用
gzip.NewReader包裹后直接传给xml.NewDecoder） - 不适用场景：确定永远小于 1MB 的配置片段——这时
xml.Unmarshal更直觉，没必要加状态机复杂度 - 关键提醒：
xml.Decoder不自动跳过注释或空白文本节点，xml.CharData类型 token 里可能全是换行和空格，必须手动strings.TrimSpace
如何避免 DecodeElement 后字段全为零值
常见错误是循环读 token 却忘了调用 decoder.DecodeElement(&v, &se)，结果结构体字段始终是零值，还查不出错在哪。
- 进入目标节点时，先判断
token.(xml.StartElement).Name.Local == "record"，别漏掉命名空间校验（见下一条） - 调用
DecodeElement时必须传入&se（即刚读到的StartElement），否则字段绑定失败 - 解析完立刻调用
decoder.Skip()跳过子树，否则后续 token 流会错位 - 想提前退出循环？先调一次
decoder.Token()消费掉当前 token，再break或return
命名空间导致匹配失败的硬伤怎么破
只要 XML 带 xmlns="http://example.com/ns"，StartElement.Name.Space 就非空，硬编码 "item" 必然失败。
- 方案一：解析前设
decoder.DefaultSpace = "http://example.com/ns"，之后所有未声明命名空间的标签都按此 URI 处理 - 方案二：匹配时同时校验
token.(xml.StartElement).Name.Space == nsURI && token.(xml.StartElement).Name.Local == "item" - 别用
xml.Name{Local: "item"}去比对——Name是输出结构，不是匹配工具 - 如果上游用前缀如
dc:title，注意token.Name.Space存的是 URI，不是前缀字符串
最易被忽略的是：没处理 xml.CharData 的前后空白，以及跳过子树时漏调 decoder.Skip()——这两个点一旦出错，token 流就彻底乱序，后面所有解析都不可信。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
