Go解析XML字段为空，主因是字段未导出（首字母小写）或xml标签名不匹配（大小写、连字符等须完全一致）；属性用xml:",attr"，文本内容用xml:",chardata"，嵌套需严格对应结构或使用路径式标签。
Go 解析 XML 文件后结构体字段全空，八成是字段没导出或 xml: 标签写错了。这不是 bug，是 encoding/xml 包的设计前提：它只看首字母大写的字段，且只按 xml: 标签里的字符串去匹配 XML 节点名——大小写、下划线、连字符，一个都不能差。
字段为空？先查导出性和 xml 标签对不对
Go 的 xml.Unmarshal 根本看不到小写字母开头的字段，比如 username string —— 无论你加不加 xml:"user_name"，它都跳过。必须写成 UserName string，再配 xml:"user_name"。
- XML 是
<user-id>alice</user-id>，结构体字段就得是UserID string `xml:"user-id"`，不能靠命名习惯自动转换 - 字段写了
xml:"name,attr"却对应了子元素（不是属性），值永远是零值，还不报错 - 想忽略某个字段？用
xml:"-"；想区分“没传”和“传了空字符串”，得用*string，不是string
属性和文本混在一起怎么取？xml:",chardata 是关键
像 <price currency="USD">29.99</price> 这种，既要 currency 属性，又要 29.99 这个值，很多人卡在“只能二选一”。其实 Go 原生支持，只是标签太冷门。
- 属性用
xml:"currency,attr"，比如Currency string `xml:"currency,attr"` - 纯文本内容用
xml:",chardata"，比如Value string `xml:",chardata"` - 别把
xml:",chardata"和xml:"text"混用：xml:"text"是找叫<text>的子元素，不是取当前标签内的文本 - 如果要连子标签一起原样拿，得换
xml:",innerxml"，不是chardata
嵌套多层却只定义了一层？数据直接掉进黑洞
XML 是树，Go 结构体也得是树。比如 <events><event><participants><participant></participant></participants></event></events>，你不能在顶层直接写 Participant []Participant `xml:"participant"` —— 中间两层 events 和 participants 没人接，数据就没了。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 要么老老实实嵌套：
Events struct { Event []struct { Participants struct { Participant []Participant `xml:"participant"` } `xml:"participants"` } `xml:"event"` } `xml:"events"` - 要么用路径式标签跳一级：
Participants []Participant `xml:"events>event>participants>participant"`（注意：只支持单层跳转，a>b>c>d会失效） - 切片字段必须带明确子元素名，比如
[]Item `xml:"item"`；光写[]Item不会自动猜 - 外层容器（如
<items>）要不要单独建 struct，取决于你是否关心它的属性或文本内容
命名空间、大文件、非法字符这些坑怎么绕
带 xmlns="http://purl.org/rss/1.0/" 的 XML，默认会被 Go 解析器当成“未知命名空间”，所有子元素都被忽略——字段全空、也不报错，纯静默失效。
- 临时解法：用
strings.ReplaceAll(xmlBytes, `xmlns="http://purl.org/rss/1.0/"`, "")预处理（仅限可信、格式固定的数据） - 更稳妥做法：改用
xml.Decoder配合Token()手动遍历，跳过命名空间校验 - 大文件别用
xml.Unmarshal—— 它是全量加载，几十 MB 就可能 OOM；改用xml.Decoder流式解析，内存恒定在 KB 级 -
©这类 HTML 实体在 XML 里非法，encoding/xml不展开也不容错；先用xmllint --noout file.xml验证合法性，再决定是否用strings.ReplaceAll补救
真正难的从来不是语法，而是 XML 实际结构和结构体之间那几层看不见的嵌套、命名空间的隐形约束、还有字段导出性这个最基础却最容易被忽略的前提。
