Go 的 XML 解析必须预先定义带正确 xml tag 的大写结构体，不支持动态解析；需注意编码转换、命名空间、DTD 处理、字段类型匹配及切片初始化；复杂场景应使用 xml.Token 手动解析。
XML 解析前必须定义结构体并正确打标签
Go 的 encoding/xml 不支持动态解析，所有字段必须提前声明为结构体字段，并用 xml tag 显式指定映射关系。漏打、打错、大小写不一致都会导致字段为空。
-
xml:"name"匹配同名 XML 元素；xml:"name,attr"匹配属性；xml:",chardata"捕获文本内容 - 嵌套元素需对应嵌套结构体，或用
xml:",any"接收未知子节点（但会丢失类型信息） - 首字母小写的字段默认被忽略（Go 可导出规则），务必大写开头
- 如果 XML 有命名空间（如
<rss xmlns="http://purl.org/rss/1.0/">），结构体字段需用xml:"rss xmlns,attr"或整体用xml.Name字段捕获
Unmarshal 时常见空值或 panic 场景
xml.Unmarshal 失败通常不 panic，而是静默跳过不匹配字段或返回 nil 错误但数据不全。典型表现是结构体字段全为零值，却没报错。
- 输入 XML 是 UTF-8 以外编码（如 GBK）会导致解析失败且无明确提示——必须先转成 UTF-8 再传入
bytes.NewReader - XML 中存在 DTD 声明（
<!DOCTYPE ...>）会触发xml: invalid character entity错误——用strings.ReplaceAll(xmlStr, "<!DOCTYPE", "<!-- DOCTYPE")临时注释掉（仅调试用） - 字段类型不匹配：XML 值为
"true"，但结构体字段是int，结果为 0 且无错误；应统一用string接收再手动转换 - 切片字段未加
xml:",omitempty"时，空元素（<items/>）不会自动初始化为空切片，而是保持nil，后续len()会 panic
处理含混合内容或任意子节点的 XML
当 XML 结构不固定（比如 HTML 片段、配置文件中允许扩展标签），不能靠静态结构体全覆盖。这时要结合 xml.Token 手动解析。
- 用
xml.NewDecoder配合Token()循环读取，区分xml.StartElement/xml.CharData/xml.EndElement - 对已知标签（如
<title>）用decoder.DecodeElement(&v, &start)提前解出；其余跳过或存为原始字节 - 注意：直接调
decoder.Token()后再调Unmarshal会出错，因为 reader 位置已偏移——应保存原始 bytes，对每个子段重新构造bytes.NewReader
decoder := xml.NewDecoder(strings.NewReader(xmlStr))
for {
t, err := decoder.Token()
if err == io.EOF {
break
}
if se, ok := t.(xml.StartElement); ok && se.Name.Local == "item" {
var item Item
decoder.DecodeElement(&item, &se) // 复用 decoder，但只解当前元素
items = append(items, item)
}
}性能与内存注意事项
xml.Unmarshal 是全量加载 + 反射解析，对大文件（>10MB）易 OOM 或明显卡顿。没有流式解构的“部分解析”捷径，只能靠分块或改用 Token 方式。
立即学习“go语言免费学习笔记（深入）”；
- 避免在循环中反复调
xml.Unmarshal([]byte(xmlStr), &v)——[]byte分配开销大；复用bytes.Reader或预分配缓冲区 - 结构体字段尽量用指针（
*string）或自定义类型（实现xml.Unmarshaler），可拦截空值、做格式校验、避免零值污染 - 若只需提取几个字段（如 RSS 的
<title>和<link>），用Token手动遍历比 Unmarshal 整个结构快 3–5 倍，内存占用低一个数量级
实际项目里，多数人卡在结构体 tag 写错或忽略了编码/命名空间问题。真正需要 Token 级控制的场景不多，但一旦 XML 来源不可控，就得提前留好退路。
