xml解析失败主因是结构体标签错误或嵌套不匹配：字段未导出、属性值非基础类型、命名空间未声明、切片/指针缺失、层级与xml树不一致等，需严格对齐xml结构并注意细节约束。
XML结构体标签写错会导致解析为空
Go的encoding/xml包靠结构体字段上的xml标签控制序列化行为，不写或写错就几乎必然失败。最常见的是把xml:"name"误写成xml:"name,attr"却忘了字段是字符串类型——属性值必须是string、int等基础类型，不能是嵌套结构体。
使用场景：读取配置文件、对接老系统接口、生成RSS/Atom等标准格式。
-
xml:",attr"只能用于基础类型字段；想把结构体字段当属性用，得先转成字符串（比如用fmt.Sprintf）再存到string字段里 -
xml:",chardata"对应文本节点内容，别和xml:",innerxml"混淆：innerxml会原样保留子元素（包括标签），chardata只取纯文本 - 字段名首字母小写（未导出）时，无论加什么标签都无效——Go不会序列化未导出字段
- 如果XML有命名空间（如
<rss xmlns="http://purl.org/rss/1.0/"></rss>），结构体字段需显式声明xml:"rss xmlns,attr"或用xml.Name字段捕获
嵌套XML元素解析失败，多半是结构体嵌套方式不对
遇到xml: unsupported type: struct { ... }或解析后子字段全空，八成是结构体嵌套没对齐XML层级。Go不支持匿名嵌入后自动展开子元素，必须严格按XML树形结构定义嵌套结构体，或用指针规避零值问题。
示例：XML中<book><author><name>Alice</name></author></book>，就不能把Author直接定义为string，而要写成：
立即学习“go语言免费学习笔记（深入）”；
type Book struct {
XMLName xml.Name `xml:"book"`
Author struct {
Name string `xml:"name"`
} `xml:"author"`
}
- 用
xml:"author>name"可以跳过中间层，但仅限于单层跳转，不支持author>contact>email这种多级 - 如果某个元素可能不存在（如可选的
<isbn></isbn>），字段类型必须是指针（*string）或使用omitempty标签，否则反序列化时会被设为零值且无法区分“没出现”和“出现但为空” - 同名多个子元素（如多个
<item></item>）必须用切片：Items []Item `xml:"item"`，不能用单个结构体
生成XML时中文乱码或缺少XML声明
默认xml.Marshal输出UTF-8字节流，但不带XML声明（<?xml version="1.0" encoding="UTF-8"?>）。如果接收方严格校验，就会报错；更隐蔽的问题是，某些Windows工具把无BOM的UTF-8当成GBK，导致中文显示为乱码。
- 手动拼接声明最稳妥：
xml.Header + string(xmlBytes)，其中xml.Header是"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" - 不要用
os.Stdout.Write直接输出xml.Marshal结果——它返回[]byte，而Write接受[]byte没问题，但若中间经过string()转换再转回[]byte，可能因编码不一致丢数据 - 如果XML内容含特殊字符（
、<code>&等），encoding/xml会自动转义，无需额外处理；但若用了xml:",innerxml"，就得自己确保内容已转义，否则生成非法XML
性能敏感场景下避免反复Marshal/Unmarshal
在高频服务（如API网关解析请求体）中，xml.Unmarshal比JSON慢约3–5倍，主要开销在反射和字符串分配。如果XML结构固定且量大，值得做两件事：缓存xml.Decoder实例、预分配切片容量。
-
xml.NewDecoder可以复用，调用decoder.Decode(&v)前用decoder.Token()跳过无关元素，减少解析深度 - 对已知最大数量的切片字段（如日志列表），在结构体中初始化容量：
Logs []Log `xml:"log"`→ 改为Logs []Log `xml:"log"`并在解码前v.Logs = make([]Log, 0, 100) - 如果只是提取少数字段（比如只取
<status>ok</status>），别整个结构体反序列化，改用xml.Decoder配合Token()流式读取，内存和CPU都省一半以上
