Go结构体可通过统一导出字段+兼容性标签（json:"x" xml:"x" yaml:"x"）同时支持JSON、XML、YAML序列化；须确保字段首字母大写、避免混用xml:",attr"与json/yaml标签、慎用map[string]interface{}。
怎么让一个 Go 结构体同时支持 JSON、XML 和 YAML 序列化
Go 的 encoding/json、encoding/xml 和 gopkg.in/yaml.v3 各自使用不同字段标签，但结构体只需一套字段定义，关键在标签对齐。别写三套 struct，用兼容性标签组合就行。
常见错误是只加 json 标签，结果 xml.Marshal 输出全是空标签，或 YAML 解析时报 yaml: unmarshal errors —— 因为字段没暴露（未导出）或标签缺失。
- 所有字段必须首字母大写（导出），否则
json/xml/yaml包都看不到 -
json标签用json:"name,omitempty"，xml用xml:"name,attr"或xml:"name"，YAML 用yaml:"name,omitempty" - 如果字段名和序列化名一致，
xml和yaml可省略标签，但json建议保留以明确控制行为 - 嵌套结构体字段默认会被展开；如需保持嵌套层级，XML 要加
xml:",omitempty"，YAML 需确保字段非 nil
示例：
type User struct {
ID int `json:"id" xml:"id" yaml:"id"`
Name string `json:"name" xml:"name" yaml:"name"`
Email string `json:"email,omitempty" xml:"email,omitempty" yaml:"email,omitempty"`
Active bool `json:"active" xml:"active" yaml:"active"`
}
如何避免 JSON 和 XML 字段名冲突导致的解析失败
JSON 和 XML 对字段名映射逻辑不同：JSON 默认忽略大小写差异（实际不忽略，但常误以为忽略），XML 则严格区分属性（xml:",attr"）与子元素（xml:"field"）。最容易踩的坑是把同一个字段既当 XML 属性又当 JSON 字段，结果反序列化时字段被覆盖或丢弃。
立即学习“go语言免费学习笔记（深入）”；
典型现象：xml.Unmarshal 成功但 json.Unmarshal 后字段为空，或者反过来；调试时发现 reflect.Value.Kind() 是 Invalid。
- XML 属性必须加
,attr后缀，例如xml:"version,attr"；没加就当成子元素，而 JSON 没这概念，会直接忽略 - 不要混用
xml:",chardata"和json:",omitempty"—— 前者只对 XML 生效，后者对 JSON 生效，但 YAML 不认chardata - 如果字段在 XML 中是属性，在 JSON/YAML 中是普通字段，建议用不同字段名隔离，比如
XMLVersion string `xml:"version,attr"`+Version string `json:"version" yaml:"version"`
怎样统一处理多格式的序列化错误和空值逻辑
不同包对 nil、零值、空字符串的处理不一致：json 默认跳过 omitempty 字段，xml 却仍生成空标签（除非显式加 omitempty），YAML 则可能输出 null 或空行。错误也分散：JSON 报 invalid character，XML 报 expected element type，YAML 报 cannot unmarshal !!str into int。
- 统一用
errors.Is(err, io.EOF)判断是否只是流结束，而非格式错误 - 对输入做预检：先用
bytes.TrimSpace去掉首尾空白，再判断是否为空，避免json.Unmarshal报invalid character - 零值字段若需保留，去掉所有
omitempty；若需统一清空，用指针字段（如*string），配合json:",omitempty"控制输出 - 错误日志里带上原始数据片段（截取前 100 字符），方便定位是哪段内容触发了
yaml: line 5: did not find expected key
为什么用 map[string]interface{} 做通用转换反而更难维护
看到“多格式”就想用 map[string]interface{} 中转？它确实能绕过 struct 定义，但代价很高：类型丢失、字段名拼写错误 runtime 才暴露、无法做字段级验证、IDE 失去跳转和补全能力。
真实场景中，90% 的多格式需求其实来自固定 schema（如配置文件、API 请求/响应），硬编码 struct 更稳。只有极少数动态字段（如 metadata）才值得用 map。
-
json.Unmarshal到map[string]interface{}后，数字默认是float64，转成int要手动断言，容易 panic - XML 转 map 需第三方库（如
github.com/basgys/goxml2json），且属性和子元素混合时结构混乱 - YAML 的锚点（
&ref）、合并（<<: *ref）在 map 中无法还原语义，只能当普通键值处理 - 真正需要灵活性时，用 interface{} + 自定义 UnmarshalJSON 方法，比全用 map 更可控
字段少、schema 稳定时，struct 是唯一靠谱选择；字段动态变化才是 map 的合理使用边界。
