xml.decoder 是唯一能高效处理百mb级xml的方案，因其流式解析仅占用几mb内存，而xml.unmarshal会全量加载导致oom；需正确调用decodeelement、skip及命名空间校验，并手动处理chardata和空白节点。
xml.Decoder 是唯一能扛住百 MB XML 的方案
别试 xml.Unmarshal，它会把整个文件读进内存再解析，100MB XML 实际占用常超 300MB，GC 压力大、OOM 风险高——这不是调优能解决的，是设计不匹配。真正可行的只有 xml.NewDecoder，它边读边解，内存只跟当前节点深度和字段长度相关，稳定在几 MB 级别。
适用场景包括：HTTP resp.Body、gzip.NewReader 包裹的压缩流、本地大文件 os.Open；不适用场景是确定永远小于 1MB 的配置片段——这时 xml.Unmarshal 更直觉，没必要加状态机复杂度。
DecodeElement 调用失败导致字段全为零值
常见错误是循环读 token 却忘了调用 decoder.DecodeElement(&v, &se)，结果结构体字段始终是零值，还查不出错在哪。
- 必须先读到
xml.StartElement，再传它的地址（&se）给DecodeElement，传错或漏传都会绑定失败 - 调用
DecodeElement后，立刻执行decoder.Skip()跳过子树，否则后续 token 流会错位 - 想提前退出循环？先调一次
decoder.Token()消费掉当前 token，再break或return -
token.(xml.StartElement).Name.Local == "record"这种判断要加命名空间校验，否则上游带xmlns就匹配不上
命名空间让匹配失效的硬伤怎么破
只要 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，不是前缀字符串
CharData 和 Skip 漏处理会让整个 token 流崩溃
最易被忽略的是两件事：xml.CharData 类型 token 里可能全是换行和空格，必须手动 strings.TrimSpace；跳过子树时漏调 decoder.Skip()——这两个点一旦出错，token 流就彻底乱序，后面所有解析都不可信。
其他细节：
-
xml.Decoder不自动跳过注释或空白文本节点，需手动判断token.Type - 遇到
xml.CharData时不做TrimSpace，会导致字符串字段开头结尾混入大量空白 - 深层嵌套建议用栈记录路径，避免硬编码层级判断
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
