Golang XML反序列化：如何传入自定义Record类型的Resp结构体

嘿，我之前处理XML解析的时候也碰到过类似的需求，想要让Resp结构体里的Records字段能灵活适配不同的具体Record类型，不用每次都写重复的Resp结构。这里有两个实用的方案，你可以根据自己的Go版本和需求来选：

方案一：用泛型重构Resp结构体（Go 1.18+推荐） #

Go 1.18引入泛型后，这个问题就变得非常简单了。我们可以把Resp改成泛型结构体，这样就能在使用时指定具体的Record类型：

// 泛型版Resp，T代表具体的Record类型
type Resp[T any] struct {
    Count   string `xml:"totalRows"`
    Records []T    `xml:"data>record"`
}

// 原有的Record类型保持不变
type DepartmentRecord struct {
    DepID string `xml:"IDFIELD"`
}

type PersonRecord struct {
    UserID string `xml:"IDFIELD"`
}

使用的时候直接指定泛型参数就行，完全不用修改Unmarshal的调用方式：

// 解析部门数据
var deptResp Resp[DepartmentRecord]
err := xml.Unmarshal(xmlData, &deptResp)
if err != nil {
    // 处理错误
}

// 解析人员数据
var personResp Resp[PersonRecord]
err = xml.Unmarshal(xmlData, &personResp)
if err != nil {
    // 处理错误
}

这个方案的好处是代码复用性极高，不用为每种Record都定义单独的Resp结构体，而且类型安全，编译时就能检查出类型错误。

方案二：自定义UnmarshalXML方法（兼容老版本Go） #

如果你还在使用Go 1.18之前的版本，没法用泛型，可以通过自定义UnmarshalXML方法来实现动态解析。核心思路是在Unmarshal过程中，先把XML解析到对应具体Record类型的临时结构体，再把数据转存到通用的Resp里：

import "encoding/xml"

type Resp struct {
    Count   string          `xml:"totalRows"`
    Records []interface{}   `xml:"-"` // 标记为忽略，自己处理解析
}

// 自定义Unmarshal方法，这里我们假设预先知道要解析成DepartmentRecord
// 如果需要动态切换类型，可以给Resp加一个类型标识字段，在方法里分支处理
func (r *Resp) UnmarshalXML(d *xml.Decoder, start xml.StartElement) error {
    // 先解析Count字段
    type tempCount struct {
        Count string `xml:"totalRows"`
    }
    var tc tempCount
    if err := d.DecodeElement(&tc, &start); err != nil {
        return err
    }
    r.Count = tc.Count

    // 解析具体的DepartmentRecord列表
    type deptTemp struct {
        Records []DepartmentRecord `xml:"data>record"`
    }
    var dt deptTemp
    // 重新解码整个元素到临时结构体
    if err := d.DecodeElement(&dt, &start); err != nil {
        return err
    }

    // 转换为[]interface{}
    r.Records = make([]interface{}, len(dt.Records))
    for i, record := range dt.Records {
        r.Records[i] = record
    }

    return nil
}

如果需要支持多种Record类型，可以给Resp加一个RecordType字段来标记要解析的类型，在Unmarshal方法里根据这个字段选择对应的临时结构体。不过这种方式代码量会大一些，不如泛型方案简洁。

内容的提问来源于stack exchange，提问作者Alex