Revel 中 RenderXml 易踩坑：字段未导出致空、嵌套重复命名空间、中文乱码；需导出字段、设 ContentType、手动加 XML 声明；解析 XML 请求须用 c.Params.Body + xml.Unmarshal；大文件 SAX 解析需重读 Body 并限流；模板渲染更适复杂 XML，注意编码与转义。
Revel 中用 RenderXml 返回 XML 响应很简单，但默认行为容易踩坑
Revel 的 RenderXml 会调用 xml.Marshal 序列化结构体，不加干预时：状态码是 200 OK，Content-Type 是 application/xml。但实际使用中常遇到三个问题：字段名未导出导致序列化为空、嵌套结构生成重复命名空间、中文乱码（缺少 声明）。
解决办法不是重写整个 Result，而是提前控制结构体标签和响应头：
- 确保结构体字段首字母大写（即导出），并显式用
xml:"name,attr"或xml:",omitempty"控制输出 - 在调用
RenderXml前手动设置c.Response.ContentType = "application/xml; charset=utf-8" - 如果必须带 XML 声明，需放弃
RenderXml，改用RenderText+ 手动拼接字符串或bytes.Buffer写入
解析请求里的 XML 数据不能只靠 Params，得用 c.Params.Body + xml.Unmarshal
Revel 默认不自动解析 application/xml 请求体，c.Params 只处理表单和 URL 查询参数。XML 请求体需要手动读取并反序列化：
-
c.Params.Body是原始[]byte，可直接传给xml.Unmarshal - 注意检查
c.Request.ContentLength是否为 0，避免空 body 导致 panic - 别用
c.Params.Get("xxx")尝试从 XML 提取字段——它根本不会解析 XML 树 - 建议封装一个辅助方法，统一处理解码错误并返回
RenderError或自定义 400 响应
想用 SAX 解析大 XML 文件？Revel 不干涉，但别在 Action 里阻塞
Revel 本身不提供 XML 解析器，xml.Decoder（Go 标准库的 SAX 风格）完全可用，但要注意执行上下文：
- 不要在 Controller Action 方法里直接用
xml.NewDecoder(c.Request.Body)——c.Request.Body可能已被中间件（如日志、CSRF）读过一次，再次读将返回空 - 正确做法是先
io.ReadAll(c.Request.Body)拿到完整字节，再用bytes.NewReader创建新 reader 交给xml.NewDecoder - 若 XML 极大（>10MB），必须加内存限制和超时，否则可能拖垮整个请求协程；推荐用
http.MaxBytesReader包裹原始 Body - Revel 的 Filter 链对 SAX 解析无感知，所有错误需在 Action 内部捕获并转为 HTTP 错误（如 413 或 400）
模板里写 XML 输出？别用 RenderXml，用 RenderTemplate 更可控
当响应内容是混合结构（比如 RSS feed、SOAP 响应体、带 CDATA 的配置片段），纯 RenderXml 很难满足格式要求。这时应退回模板渲染：
- 创建
views/rss/index.xml模板，用 Go template 语法输出 XML 结构 - 在 Action 中调用
c.RenderTemplate("rss/index.xml", data) - 关键点：
c.Response.ContentType必须设为application/rss+xml或对应类型，且模板开头要加{{printf "" | safe}} - 所有动态内容（尤其是用户输入）必须用
{{.Field | html}}或{{.Field | xml}}过滤，否则极易引入 XML 注入漏洞
XML 场景下最易被忽略的是编码一致性：HTTP header 的 charset、XML 声明里的 encoding、Go 字符串内部的 UTF-8 表示，三者必须对齐。任何一处错位都会导致中文字段显示为 或解析失败。
