Go的xml.Unmarshal不提供格式化解析能力，仅做反序列化；字段必须首字母大写且xml标签严格匹配XML元素名，嵌套需显式声明，属性用",attr"、文本用",chardata"，大文件应改用xml.Decoder流式处理。
Go 的 xml.Unmarshal 本身不提供“格式化”解析能力 —— 它只做反序列化，不校验、不美化、不补全。所谓“格式化解析”，实际是指在解析前/后对 XML 内容做结构校验、命名空间剥离、空元素处理、编码归一等操作，确保 xml.Unmarshal 能稳定产出有效数据。
xml.Unmarshal 总是返回零值？先检查字段导出性和标签匹配
这是最常卡住人的点：结构体字段全是零值，err 却为 nil。
- 字段必须首字母大写（如
Name），小写字段（如name）会被xml.Unmarshal完全忽略 -
xml:"tag"标签里的名字要和 XML 实际元素名**严格一致**（大小写、连字符都不能错），比如<user-id>必须写成Name string `xml:"user-id"` - 嵌套结构体字段若没加
xml:"child"，就无法命中子元素；切片字段（如[]Item）才能接收多个同名元素，单个结构体字段只会取第一个 - 根元素名不匹配也会静默失败 —— 比如 XML 是
<rss>...</rss>，但结构体没声明XMLName xml.Name `xml:"rss"`，且顶层字段又没对应rss标签，就会漏掉整个层级
带命名空间的 XML 解析失败？别硬扛，先剥离或换路径标签
像 <rss xmlns="http://purl.org/rss/1.0/"> 这类带默认命名空间的 XML，xml.Unmarshal 默认会跳过所有元素 —— 因为它把 rss 当作 {http://purl.org/rss/1.0/}rss，而你的 xml:"rss" 标签没声明命名空间，自然匹配不上。
- 最简单办法：用正则或
bytes.ReplaceAll预处理 XML 字节流，删掉xmlns="..."属性（仅限你确定无歧义时） - 更稳妥做法：用路径标签语法，例如
Items []Item `xml:"channel>item"`，绕过命名空间干扰，直接按层级抓取 - 真要保留命名空间语义，得在结构体字段里显式声明 URI，如
Channel Channel `xml:"http://purl.org/rss/1.0/ channel"`，但标准库支持有限，容易出错
属性、文本、混合内容怎么一起拿？每个都要显式声明
xml.Unmarshal 不会自动推断你想取属性还是文本 —— 不声明，就丢。
立即学习“go语言免费学习笔记（深入）”；
- 属性必须用
,attr：例如ID string `xml:"id,attr"`对应<item id="123"> - 元素内纯文本用
,chardata：例如Content string `xml:",chardata"`对应<desc>hello</desc>中的hello - 同时有属性 + 子元素 + 文本？三者都得声明，且顺序无关；但若还希望捕获未定义子元素，加
,any字段占位，否则子元素可能被跳过 - 别用
,innerxml除非你真要原始 XML 片段 —— 它会把子元素原样当字符串，后续还得二次解析
大文件解析内存爆了？Unmarshal 不是万能解药
xml.Unmarshal 把整份 XML 加载进内存再解析，几十 MB 就可能 OOM。这不是 bug，是设计定位决定的 —— 它面向已知结构、规模可控的配置或响应体。
- 真实场景（如 RSS 源、日志 XML 流）请改用
xml.Decoder：逐 token 处理，内存占用恒定在 KB 级 - 关键细节：
decoder.Token()返回值必须判空，否则遇到 EOF 会 panic；用decoder.Skip()主动跳过深层嵌套，别靠结构体字段自动忽略 - 如果非要用
Unmarshal，至少前置加io.LimitReader控制最大读取长度，防恶意超大输入
真正难的不是写对标签，而是判断该不该用 Unmarshal —— 结构固定、体积小、开发快，选它；流式、未知深度、内存敏感，就得切到 Decoder 手动驱动。
