xml.Unmarshal解析大XML会OOM，因其必须全量加载文本并构建DOM树，100MB文件常占200MB+内存；而xml.Decoder流式解析内存稳定在几MB，适用于日志、HTTP流等大数据场景。
Go 的 xml.Unmarshal 不能直接处理大文件或需要保序、混合结构的 XML；必须切换到 xml.Decoder 流式解析，否则内存暴涨、顺序丢失、命名空间失效都是大概率事件。
为什么 xml.Unmarshal 解析大 XML 会 OOM
它把整个 XML 文本读进内存，再构建 DOM 树，最后递归填充结构体。文件体积和内存占用基本 1:1，100MB XML → 至少 200MB+ Go heap（含字符串拷贝、切片扩容）。GC 压力大，解析中途可能被系统 kill。
-
xml.Unmarshal只适合已知结构、KB～MB 级别、能全量加载的场景（如配置片段、小响应体） - HTTP 响应体、日志导出、RSS 全量抓取等场景，必须用
xml.NewDecoder+io.Reader - 别在循环里对每个
<item>子串调xml.Unmarshal—— 这只是把 OOM 拆成多次，没解决根本问题
如何用 xml.Decoder 正确提取重复元素
核心是靠 decoder.Token() 推进，识别 xml.StartElement 后决定是否解码该节点。不是“跳过无关标签”，而是“只消费目标标签”。
- 每次
decoder.Token()后必须检查 error，nil表示 EOF，io.EOF是合法终止，其他 error 需处理 - 匹配目标元素时，用
se.Name.Local == "item"，不要硬写带命名空间的"ns:item"（标准库不认） - 调
decoder.DecodeElement(&v, &se)前，v字段仍需首字母大写 + 正确xml:tag，否则字段为空 - 用
decoder.Skip()跳过深层嵌套子树（比如你只关心顶层<entry>，里面<content><html>...全跳）
怎么同时拿到属性和文本内容（比如 <price currency="USD">29.99</price>）
结构体字段必须显式声明两部分：属性用 xml:",attr"，文本用 xml:",chardata"。漏掉任一，对应数据就丢。
立即学习“go语言免费学习笔记（深入）”；
- 字段名大小写必须导出（
Currency✅，currency❌） -
Price float64 `xml:",chardata"`会尝试把29.99转为 float64；若文本含空格或单位（如"29.99 USD"），得改用string+ 手动解析 - 同一元素下不能有两个
xml:",chardata"字段，否则 panic；也不能混用xml:",chardata"和xml:"child"（除非加xml:",any"占位）
命名空间和混合节点顺序怎么破
标准库对命名空间是“静默忽略”——<rss xmlns="http://purl.org/rss/1.0/"> 里的 <item>，用 xml:"item" 标签永远匹配不上。混合节点（如 <offer> 和 <product> 交错）也无法靠结构体嵌套保序。
- 最简方案：预处理 XML 字符串，
bytes.ReplaceAll(xmlBytes, []byte(`xmlns="..."`), nil)，前提是不依赖命名空间语义 - 保序需求强时，放弃
xml.Unmarshal，改用xml:",any"+ 自定义UnmarshalXML方法，在运行时按start.Name.Local动态分发 - 别试图用正则删命名空间前缀（如
ns:item→item），容易误杀内容里的冒号
流式解析真正难的不是写几行 Token() 循环，而是错误边界处理：Token 返回 nil 之后不能再调用任何方法，DecodeElement 失败后 decoder 内部状态可能已损坏，Skip 的深度要和实际 XML 层级对齐——这些细节不踩一次坑很难记住。
