RenderXml 必须传入含导出字段且带xml tag的Go struct，不支持string、map或[]byte；默认设Content-Type: application/xml和Status: 200，但手动设置后不会覆盖；pretty=true仅开发环境缩进，不修复命名或格式问题；序列化失败时静默返回空响应，需手动验证。
RenderXml 必须传入可序列化的 Go struct
Revel 的 RenderXml 不接受字符串、map 或 []byte，只支持能被 xml.Marshal 处理的结构体（含导出字段）。传入非结构体或含未导出字段的 struct 会静默返回空响应或 500 错误，且无明确提示。
- ✅ 正确：定义带
xmltag 的导出字段 - ❌ 错误：
return c.RenderXml(map[string]string{"a": "b"})—— 会 panic - ❌ 错误：
type Resp struct { msg string }—— 字段未导出，序列化后为空
示例：
type User struct {
ID int `xml:"id"`
Name string `xml:"name"`
}
func (c App) GetUser() revel.Result {
return c.RenderXml(User{ID: 123, Name: "Alice"})
}
Content-Type 和状态码不能靠 RenderXml 自动设置
RenderXml 默认设 Content-Type: application/xml 和 Status: 200，但一旦你手动设置了 c.Response.Status 或 c.Response.ContentType，它不会覆盖——也就是说，如果你在调用前改了这些值，RenderXml 就照用你设的，不会“纠正”回 XML 默认值。
- 常见坑：在中间件或 action 开头写了
c.Response.ContentType = "text/plain"，后面再RenderXml，结果响应头还是text/plain - 安全做法：显式重置，或在
RenderXml后再设（但顺序要对）
正确写法：
func (c App) GetReport() revel.Result {
c.Response.Status = http.StatusOK
c.Response.ContentType = "application/xml"
return c.RenderXml(Report{...})
}
pretty=true 配置只影响开发环境缩进，不改变结构
Revel 会检查配置项 results.pretty（默认 false），若为 true，则内部使用 xml.MarshalIndent 而非 xml.Marshal。这仅添加换行和空格，不影响 XML 语义或解析兼容性。
- 生产环境建议保持
results.pretty=false，减小响应体积 - 该配置对字段命名、属性、CDATA 等无任何影响，别指望它修复格式问题
- 如果需要自定义命名空间或处理特殊字符，必须靠 struct tag 控制，例如
XMLName xml.Name `xml:"rss"`
错误 XML 输出时没有 fallback，客户端只能收到空或乱码
当 struct 中字段类型不支持 XML 序列化（如 func()、chan、含循环引用的指针），xml.Marshal 会返回 error，而 Revel 的 RenderXml 不捕获也不记录这个 error，直接返回空 body + 200 状态码。前端看到的是空白响应或解析失败。
- 调试方法：在 action 中先手动调用
xml.Marshal并检查 error - 临时兜底：用
defer+recover捕获 panic（虽然xml.Marshal通常不 panic，但嵌套结构可能触发） - 真正健壮的做法：封装一个
SafeRenderXml辅助函数，在日志中打印序列化失败详情
关键点就在这里：Revel 把 XML 序列化当成“一定成功”的黑盒，但实际 Go 的 xml 包很脆弱，尤其遇到时间、浮点精度、nil 接口等边界情况时。别跳过验证。
