XML 还没有从工程世界消失
现在很多新接口都用 JSON，但 XML 依然存在于不少地方：老系统接口、支付或银行协议、配置文件、RSS、Sitemap、办公文档格式。Go 标准库提供了 encoding/xml，可以像处理 JSON 一样把 XML 映射到结构体，也可以用流式方式逐个 token 解析。
XML 比 JSON 更啰嗦，也多了属性、命名空间、文本节点、嵌套元素等概念。入门阶段不必一口气掌握所有细节，只要能读懂常见结构、正确写标签、处理错误，就能应付很多对接任务。
这篇文章用一个服务配置和一个订单 XML 做例子，讲解 encoding/xml 的基础用法。
解析简单 XML
XML：
<config>
<name>demo-service</name>
<port>8080</port>
</config>
结构体：
type Config struct {
XMLName xml.Name `xml:"config"`
Name string `xml:"name"`
Port int `xml:"port"`
}
解析：
var cfg Config
if err := xml.Unmarshal(data, &cfg); err != nil {
return err
}
fmt.Println(cfg.Name, cfg.Port)
XMLName 可以帮助确认根元素名称。它不是必须字段，但在配置解析里很有用。
从文件读取：
func LoadConfig(path string) (Config, error) {
data, err := os.ReadFile(path)
if err != nil {
return Config{}, fmt.Errorf("read config: %w", err)
}
var cfg Config
if err := xml.Unmarshal(data, &cfg); err != nil {
return Config{}, fmt.Errorf("parse config: %w", err)
}
return cfg, nil
}
解析成功后仍然要做业务校验：
if cfg.Port <= 0 {
return Config{}, fmt.Errorf("port must be positive")
}
解析属性
XML 属性：
<service name="user-api" enabled="true">
<port>8080</port>
</service>
结构体：
type Service struct {
Name string `xml:"name,attr"`
Enabled bool `xml:"enabled,attr"`
Port int `xml:"port"`
}
,attr 表示字段来自属性，而不是子元素。
解析：
var service Service
if err := xml.Unmarshal(data, &service); err != nil {
return err
}
属性适合短小元信息，复杂内容通常放子元素。对接外部 XML 时，结构由对方决定；自己设计配置时，尽量保持简单。
嵌套元素和切片
订单 XML：
<order id="1001">
<user>xiaolin</user>
<items>
<item sku="book-go">
<name>Go 入门书</name>
<quantity>1</quantity>
</item>
<item sku="sticker">
<name>贴纸</name>
<quantity>3</quantity>
</item>
</items>
</order>
结构体：
type Order struct {
ID int64 `xml:"id,attr"`
User string `xml:"user"`
Items []OrderItem `xml:"items>item"`
}
type OrderItem struct {
SKU string `xml:"sku,attr"`
Name string `xml:"name"`
Quantity int `xml:"quantity"`
}
xml:"items>item" 表示进入 items 子元素，再读取多个 item。
使用：
var order Order
if err := xml.Unmarshal(data, &order); err != nil {
return err
}
for _, item := range order.Items {
fmt.Println(item.SKU, item.Quantity)
}
XML 标签要和结构严格对应。字段解析不出来时，先检查路径、属性标记和大小写。
输出 XML
编码：
order := Order{
ID: 1001,
User: "xiaolin",
Items: []OrderItem{
{SKU: "book-go", Name: "Go 入门书", Quantity: 1},
},
}
data, err := xml.MarshalIndent(order, "", " ")
if err != nil {
return err
}
fmt.Println(xml.Header + string(data))
xml.Header 是：
<?xml version="1.0" encoding="UTF-8"?>
如果要写到响应或文件，可以用 Encoder：
encoder := xml.NewEncoder(w)
encoder.Indent("", " ")
if err := encoder.Encode(order); err != nil {
return err
}
流式解析大 XML
大文件不要用 xml.Unmarshal 全量加载。使用 xml.Decoder.Token 逐 token 读取：
func CountItems(r io.Reader) (int, error) {
dec := xml.NewDecoder(r)
var count int
for {
tok, err := dec.Token()
if err == io.EOF {
break
}
if err != nil {
return 0, err
}
if se, ok := tok.(xml.StartElement); ok && se.Name.Local == "item" {
count++
}
}
return count, nil
}
流式解析内存稳定，但代码更冗长。混合策略是：用 Decoder 定位感兴趣的分支，再用 dec.DecodeElement 读入结构体。
常见问题 FAQ
Q: XML 标签支持命名空间吗？
A: 支持。xml.Name 包含空间和本地名：
type Root struct {
XMLName xml.Name `xml:"http://example.com/ns root"`
}
命名空间处理可能复杂，入门时先掌握无命名空间场景。
Q: Unmarshal 会忽略未知字段吗？
A: 默认忽略。这是优点也是风险：结构体漏写字段时不会报错，容易遗漏数据。关键配置解析后建议做完整性校验。
Q: 大小写敏感吗？
A: 是的。标签名和 XML 元素名大小写要匹配。如果外部系统命名不统一，可以用多个字段配合 ,any 标签。
常见陷阱
- 忘记解析后校验：XML 解析成功不代表业务合法。端口必须在 1-65535，ID 不能为 0。
- 嵌套路径写错：
items>item要两个>，多一个少一个都匹配不到。 - 混合读写：解析和编码时结构体字段都想成双向映射，但实际上某些标签组合支持程度不同。
- 没有设置编码：输出时记得加
xml.Header，否则某些解析器可能默认使用非 UTF-8 编码。
对比表
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 配置文件 | xml.Unmarshal | 结构清晰，标签直观 |
| 大文件 | xml.Decoder.Token | 内存可控，可中断 |
| RSS/Sitemap | xml.NewDecoder | 流式读取，增量处理 |
| 对外输出 | xml.MarshalIndent | 格式化友好 |
小结
Go 的 encoding/xml 可以通过结构体标签处理 XML 元素、属性和嵌套路径。简单 XML 用 xml.Unmarshal 很方便，大文件或复杂流可以用 xml.Decoder。解析后不要忘记业务校验，尤其是配置文件和外部接口。流式解析适合内存敏感场景，但状态管理更复杂。
XML 虽然不如 JSON 常见，但仍然是工程世界的一部分。掌握标准库基本用法，在遇到老系统、RSS、Sitemap 或企业接口时，就不会手忙脚乱。写 XML 代码时建议搭配单元测试验证结构体映射正确，避免上线后才发现字段为空。
命名空间处理进阶
当 XML 使用命名空间时，结构体标签需要更精确：
type RSS struct {
XMLName xml.Name `xml:"http://www.w3.org/2005/Atom feed"`
Title string `xml:"http://www.w3.org/2005/Atom title"`
Entries []Entry `xml:"http://www.w3.org/2005/Atom entry"`
}
type Entry struct {
ID string `xml:"http://www.w3.org/2005/Atom id"`
Title string `xml:"http://www.w3.org/2005/Atom title"`
Updated string `xml:"http://www.w3.org/2005/Atom updated"`
}
这段代码展示了 Atom feed 的解析方式，命名空间声明较长但语义清晰。
跳过未知字段与部分读取
有时你只需要读取 XML 中的某些字段，其他可以忽略：
type PartialConfig struct {
Name string `xml:"name"`
Port int `xml:"port"`
// 其他字段忽略
}
encoding/xml 默认忽略未映射字段。但要注意：如果某些字段是业务必需的，解析后必须校验，不能靠"没报错就是完整"来推断。
CDATA 处理
文本节点中如果有特殊字符，XML 可能使用 CDATA：
<description><![CDATA[This is <special> text & more]]></description>
结构体接收时：
type Article struct {
Description string `xml:"description"`
}
CDATA 内容会自动展开为普通字符串，调用方正常读取即可。
用 xml.Decoder 做条件解析
func ExtractOrderIDs(r io.Reader) ([]string, error) {
dec := xml.NewDecoder(r)
var ids []string
for {
tok, err := dec.Token()
if err == io.EOF {
break
}
if err != nil {
return nil, err
}
if se, ok := tok.(xml.StartElement); ok {
if se.Name.Local == "order" {
for _, attr := range se.Attr {
if attr.Name.Local == "id" {
ids = append(ids, attr.Value)
}
}
}
}
}
return ids, nil
}
这种只提取部分数据的读法，比全量 Unmarshal 更高效，内存也更省。
常见问题补充 FAQ
Q: 如何解析 XML 中的日期时间？
A: 先按字符串接收，再用 time.Parse 转换。encoding/xml 没有内置时间解析支持，但这让时区控制更灵活。
Q: XML 中有换行的文本节点怎么处理？
A: 默认会保留换行和空白。可以用 strings.TrimSpace 清理，或者在结构体处理逻辑中判断。
Q: 能自定义 UnmarshalXML 吗？
A: 对复杂逻辑可以实现 xml.Unmarshaler 接口，接管单个类型的解析过程。
func (d *MyDate) UnmarshalXML(dec *xml.Decoder, start xml.StartElement) error {
var s string
if err := dec.DecodeElement(&s, &start); err != nil {
return err
}
t, err := time.Parse("2006-01-02", s)
if err != nil {
return err
}
*d = MyDate(t)
return nil
}
最佳实践
- 先 Unmarshal 再校验：XML 解析不会检查业务规则。
- 大文件用 Decoder：不要全量加载到内存。
- 保持标签和字段名一致：大小写、路径层级都要严格对应。
- 统一编码：确保输出始终带
xml.Header。 - 为关键路径写测试：尤其是嵌套切片和属性解析容易出错。
实战场景：Sitemap 解析
Sitemap 是 XML 的典型应用：
type URLSet struct {
XMLName xml.Name `xml:"urlset"`
URLs []URL `xml:"url"`
}
type URL struct {
Loc string `xml:"loc"`
LastMod string `xml:"lastmod"`
ChangeFreq string `xml:"changefreq"`
Priority string `xml:"priority"`
}
func ParseSitemap(data []byte) ([]URL, error) {
var set URLSet
if err := xml.Unmarshal(data, &set); err != nil {
return nil, err
}
return set.URLs, nil
}
这类解析场景在 SEO 工具、爬虫项目中非常常见。结构体映射清晰后，解析代码变得很直觉化。
最后提示
XML 比 JSON 严格，但 Go 标准库已经处理了很多边界情况。遇到解析失败不要急着换一个库，先检查结构体标签是否和 XML 结构对应。把问题拆解为"先拿到 token，再判断类型，再映射字段"，能降低debug难度。XML 不会消失，学会它不是为了怀旧，而是为了在需要时能从容应对。
在实际对接企业级系统时，XML 的复杂程度往往高于示例。ION 协议、银行报文、SOAP 服务都可能用到多层嵌套、命名空间和属性混用。提前准备好测试样本和对应的结构体映射，是减少返工的有效方法。把测试数据放入版本控制，让结构调整时有可验证的基准。
随着 Go 版本的演进，encoding/xml 也在逐步完善。虽然目前它的使用不如 JSON 频繁，但在金融、电信、政务等领域，XML 仍然是主流数据交换格式。熟练掌握 encoding/xml 的用法，是 Go 后端工程师的基本功之一。在大型项目中，建议为 XML 解析层编写独立的 adapter 包，封装结构体定义、解析逻辑和校验规则，让业务代码不需要直接和 XML 打交道。这样即使外部接口格式发生变化，也只需要修改 adapter 层，而不会影响核心业务逻辑。这就是抽象和封装带来的长期价值。
更多实战建议
在实际项目中处理 XML 时，经常会遇到以下挑战：第一，外部系统的 XML 格式文档不完整，需要反复调试来确认正确的结构体标签。第二，同一接口在不同版本中返回的 XML 结构可能有细微差异，导致解析失败。第三，XML 中的字符编码问题可能导致解析异常。针对这些问题，建议先在本地建立完整的测试用例，覆盖正常 case、空元素 case、缺失属性 case 和特殊字符 case。把测试数据放入版本控制，确保后续修改不会破坏已有的解析逻辑。此外，对于外部 XML 接口，建议在 adapter 层做一层防御性解析：允许部分字段缺失，提供合理的默认值，而不是在解析阶段就因为一个小字段的缺失而整体失败。这种"容错解析"的策略，在实际对接中非常有价值，能显著提高系统的健壮性和兼容性。
最后，关于 XML 编码输出，还需要注意缩进和换行的控制。xml.MarshalIndent 可以指定前缀和缩进字符串，默认使用两个空格通常是合理的选择。如果下游系统对标点符号有特殊要求（比如某些老旧银行系统要求特定换行格式），可以在 Marshal 后用字符串替换来调整。在序列化阶段，确保所有中文字符已经正确处理为 UTF-8，必要时在响应头中显式声明 encoding="UTF-8"。总之，XML 处理不是一次性任务，而是需要随着业务增长不断完善的基础设施。
掌握这些基础后，进一步学习 XML Schema (XSD) 验证、XPath 查询等高级主题会更容易，能应对更复杂的 XML 数据集成场景。
养成在测试用例中覆盖边界情况的习惯，是 XML 解析稳定性的重要保障。写代码时多花十分钟写好测试，线上就能少花数小时排错。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。