Beego中JSON与XML请求体解析均需手动反序列化，但JSON用json.Unmarshal()、XML用encoding/xml且依赖copyrequestbody=true；两者均要求字段首字母大写并正确配置tag，且路由不自动按Accept头分发。
Beego 中 JSON 与 XML 请求体解析方式不同
Beego 默认不自动解析 RequestBody，无论传的是 JSON 还是 XML，都得手动反序列化。但两者解析路径和依赖条件有明显区别：
- JSON 解析只需标准库
json.Unmarshal()，无额外依赖，结构体字段必须首字母大写（exported），且建议加jsontag 显式控制键名映射 - XML 解析依赖
encoding/xml，同样要求字段 exported，但需用xmltag；若请求体含命名空间、CDATA 或自闭合标签，容易静默失败或字段为空 - Beego 路由不按内容类型自动分发——
/hello/json和/hello/xml是两个独立路由，不能靠Accept头自动切换 handler
copyrequestbody = true 是 XML 解析的隐性前提
Beego 默认会复用 RequestBody 的底层 reader，一旦被中间件或日志读过一次，后续 this.Ctx.Input.RequestBody 就是空字节切片。这对 XML 尤其致命，因为 xml.Unmarshal() 对输入敏感，空输入不报错但字段全零值。
- 必须在
conf/app.conf中显式设置copyrequestbody = true - 该配置影响所有请求体读取，不只是 XML；设为
false时，json.Unmarshal()也可能失败，但因 JSON 错误更易触发 panic 或明确 error，反而更容易暴露问题 - 没开这个开关，
this.Ctx.Input.RequestBody在 controller 里首次读取后就变空，第二次读（比如调试时再打印一遍）就会看到[]
ServeJSON 与 ServeXML 输出行为差异
ServeJSON() 和 ServeXML() 都会设置对应 Content-Type 并序列化 this.Data["json"] 或 this.Data["xml"]，但实际输出受运行模式影响：
- 开发模式（
runmode = dev）下，输出带缩进和换行的可读格式；生产模式（runmode = prod）下自动压缩，无空白字符 -
ServeJSON()序列化时会忽略 struct 中未导出字段（小写字母开头），ServeXML()同理，但若字段有xml:"-"tag，也会跳过——这点常被忽略，导致 XML 输出意外缺失字段 - 两者都不校验数据合法性：传
nil指针给ServeJSON()会返回null，传空 struct 给ServeXML()可能生成空标签或直接 omit，行为取决于字段 tag 和零值处理逻辑
Accept 头驱动格式切换需手动实现
Beego 不像 Spring Boot 或 Express 那样内置基于 Accept 头的 content-negotiation。想让同一个 URL（如 /api/user）根据客户端请求头返回 JSON 或 XML，必须自己判断：
- 用
this.Ctx.Input.Header("Accept")获取头值，匹配application/json或application/xml - 不能只看是否包含
json字符串——有些客户端发Accept: */*或Accept: application/vnd.api+json，硬匹配会漏掉 - 更稳妥的做法是用
mime.ParseMediaType()解析，并比较主类型和子类型，再 fallback 到默认格式 - 别在 handler 里混用
this.Data["json"]和this.Data["xml"]——ServeJSON()只读前者，ServeXML()只读后者，写错字段名会导致空白响应
Beego 对 JSON 和 XML 的支持是“可用”，但不是“开箱即用”。最常踩的坑不在语法或 tag，而在 copyrequestbody 开关、Accept 头的手动分发、以及 struct 字段可见性与 tag 的一致性——这三个点没对齐，90% 的解析失败就发生在这里。
