xml.unmarshal 必然导致 oom，应使用 xml.newdecoder 流式解析；需配 decodeelement + skip，注意命名空间匹配与 chardata 清理。
别用 xml.Unmarshal 解析大型 XML 文件——它必然触发 OOM，不是“可能”，是设计上就扛不住。真正能用的只有 xml.NewDecoder 流式解析，内存稳定在几 MB，和文件大小无关。
为什么 xml.Unmarshal 一定会崩
xml.Unmarshal 要求输入是完整 []byte，内部会先调 io.ReadAll 把整个文件读进内存。100MB XML 文件实际堆占用常超 300MB，尤其含大量文本或嵌套时。这不是配置问题，是函数签名决定的：它没有 io.Reader 接口参数，根本没法流式处理。
- 别碰
os.ReadFile+xml.Unmarshal组合，加//nolint也没用 - HTTP 响应体、gzip 解压流、本地大文件句柄，都必须直传给
xml.NewDecoder - 想试
xml.Unmarshal？只限 KB 级配置文件或单元测试 mock 数据
xml.NewDecoder 必须配 DecodeElement 才有效
光调 decoder.Token() 只能拿到 token 类型（StartElement、CharData 等），但不会自动绑定字段值。结构体字段全为零值，真凶就是漏了 decoder.DecodeElement(&v, &se)。
- 进入目标节点后，必须用刚读到的
se（类型为xml.StartElement）取地址传入，传nil或错变量等于白做 - 每次
DecodeElement后立刻跟decoder.Skip()，否则 token 流错位，后续解析全乱 - 想提前退出循环？先调一次
decoder.Token()消费当前 token，再break，否则下轮DecodeElement从错位置开始
命名空间匹配失败的两种解法
XML 里有 xmlns="http://example.com/ns"，但硬比 token.(xml.StartElement).Name.Local == "item" 必然失败——因为 Name.Space 非空，而 Local 只是局部名。
- 方案一：解析前设
decoder.DefaultSpace = "http://example.com/ns"，之后无前缀标签都按此 URI 处理 - 方案二：匹配时同时校验
token.(xml.StartElement).Name.Space == nsURI且token.(xml.StartElement).Name.Local == "item" - 别用
xml.Name{Local: "item"}去比对——那是输出结构，不是匹配工具；上游若用前缀如dc:title，注意token.Name.Space存的是 URI，不是前缀字符串
CharData 和 Skip 漏处理等于放弃整个 token 流
xml.Decoder 不自动跳过注释或空白文本节点。遇到 xml.CharData 类型 token，不手动 strings.TrimSpace，字符串字段开头结尾就混入大量换行和空格；漏掉 decoder.Skip()，深层嵌套时 token 流直接偏移，后续所有解析不可信。
- 每个
xml.CharData都要strings.TrimSpace(string(data))，不能原样赋值 - 每个
DecodeElement后建议紧跟decoder.Skip()，别指望“后面再跳” - 嵌套深时，用栈记录路径比硬编码层级更可靠，比如
stack = append(stack, se.Name.Local)，出 EndElement时 pop
流式解析的复杂点不在代码量，而在状态机控制——token 顺序、Skip 时机、命名空间上下文，三者错一个，整个解析链就断。最容易被忽略的是：decoder.Token() 返回的 xml.CharData 可能全是空白，而你没 trim 就存进数据库，查出来字段开头一堆 \n。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
