c.xml()和c.yaml()要求结构体字段首字母大写且显式声明xml:"tag"或yaml:"key"标签，否则静默忽略；xml支持omitempty，yaml不支持且更易因缩进或nil指针panic。
直接用 c.XML() 和 c.YAML() 就能返回对应格式，但字段标签、结构体导出规则、空值处理这些地方一不留神就出错。
XML 返回时 struct 字段必须大写且加 xml 标签
Go 的反射机制只能访问导出（首字母大写）字段，c.XML() 依赖反射序列化，小写字段会被忽略。另外不加 xml 标签会导致字段名直接变成 XML 元素名，和预期不符。
- 字段名必须首字母大写，否则不会出现在 XML 中
- 推荐显式写
xml:"user_name,attr"控制元素名或是否为属性 - 如果结构体嵌套，根元素名默认是结构体类型名（如
User→<user></user>），想改就用xml:"root_name"覆盖 -
omitempty在 XML 中同样生效：Age int `xml:"age,omitempty"`，零值字段不输出
示例：
type User struct {
Name string `xml:"user_name"`
Email string `xml:"email,attr"`
Age int `xml:"age,omitempty"`
}
c.XML(200, User{Name: "Lena", Email: "l@x.com"}) // 输出 <user><user_name>Lena</user_name><email>l@x.com</email></user>
YAML 返回对字段大小写和标签更敏感
c.YAML() 同样只序列化导出字段，但它不支持 omitempty（YAML 库 go-yaml 不识别该 tag），而且默认会把空字符串、零值都原样输出，容易污染响应。
- 字段必须大写，
name string这种不会出现在 YAML 里 -
yaml:"user_name"是必需的，否则字段名可能带下划线或全小写（取决于 struct 命名） - 没有
omitempty等效行为，想跳过零值得手动预处理，比如过滤掉Age: 0字段再传入 - map 类型可用
gin.H，但注意 key 必须是 string，且值不能是未导出 struct
示例：
type Config struct {
Host string `yaml:"host"`
Port int `yaml:"port"`
}
c.YAML(200, Config{Host: "localhost", Port: 8080}) // 输出 host: localhost\nport: 8080
Content-Type 和客户端 Accept 头不匹配时的行为
Gin 的 c.XML() 和 c.YAML() 不做协商，它只按方法名硬设 Content-Type：前者是 application/xml，后者是 application/x-yaml（不是 application/yaml，部分老客户端可能不认）。
- 浏览器直接访问
/someXML通常能正常渲染，但某些前端库（如 axios）默认不解析 XML，需手动设responseType: 'document' - YAML 响应在浏览器里常被当成纯文本下载，因为多数浏览器没注册
application/x-yamlMIME 类型 - 如果要根据
Accept头自动选格式，得自己写中间件判断并分发到不同 handler，Gin 不内置 content-negotiation
XML 与 YAML 的性能和调试差异
两者底层序列化开销接近，但调试体验差很多：XML 有标准验证工具（如 xmllint），YAML 缩进敏感，少个空格就解析失败，且 Gin 不报具体行号错误。
- XML 错误一般在客户端报 “well-formed” 问题，服务端日志无提示
- YAML 如果传入含 tab 字符的字符串或结构体里有 nil 指针，
c.YAML()会 panic，必须确保数据干净 - 生产环境建议对 YAML 响应加 recover 中间件，避免因数据问题整个请求崩溃
- 测试时优先用
gin.H验证逻辑，再换 struct；struct 一多，标签写错一个就静默丢字段
真正麻烦的不是调哪个方法，而是 struct 标签写对没、字段导出了没、空值要不要传——这些细节不检查，返回的 XML/YAML 看似成功，实际字段缺失或格式错乱，前端连报错都收不到。
