Go xml.Encoder 怎么给流式 XML 输出统一缩进

给流式 XML 输出统一缩进，关键是在第一次写入前对同一个 xml.Encoder 调用 Indent：

enc := xml.NewEncoder(w)
enc.Indent("", "  ") // 第一参数是每行前缀，第二参数是每层缩进
if err := enc.Encode(document); err != nil {
    return err // 编码失败要把错误交给上层处理
}

这里的缩进不是把已经生成的 XML 字符串重新格式化，而是让 Encoder 在输出元素时根据当前嵌套深度插入换行和缩进。流式写入时若直接使用 EncodeToken，还要在合适的边界显式调用 Flush；结束时用 Close 收尾并检查 XML 是否仍有未闭合元素。

先把 Indent 放在 Encoder 的写入入口

xml.NewEncoder 接收一个 io.Writer，之后由这个 Encoder 负责把 Go 值或 XML token 写到目标流。Indent(prefix, indent) 设置的是 Encoder 的输出格式：元素从新行开始，行首先放 prefix，再根据嵌套层级重复放置 indent。

因此最稳妥的习惯是：创建 Encoder 后立即配置缩进，再开始 Encode 或 EncodeToken。这样一个流中的所有元素都使用同一套格式。

package main

import (
    "bytes"
    "encoding/xml"
    "fmt"
    "log"
)

type Catalog struct {
    XMLName xml.Name `xml:"catalog"`
    Items   []Item   `xml:"item"`
}

type Item struct {
    ID    string `xml:"id,attr"`
    Title string `xml:"title"`
}

func main() {
    var buf bytes.Buffer
    enc := xml.NewEncoder(&buf)
    enc.Indent("", "  ") // 两个空格代表每深入一层增加的缩进

    value := Catalog{Items: []Item{{ID: "A-1", Title: "键盘"}}}
    if err := enc.Encode(value); err != nil {
        log.Fatal(err) // Encode 的错误可能来自底层 Writer 或 XML 编码
    }
    fmt.Print(buf.String())
}

这个例子使用内存缓冲区只是为了说明输出位置；在实际服务中，w 可以是文件、HTTP 响应或压缩器。缩进本身不改变 struct 标签，也不负责决定 XML 元素的业务层次。

prefix 和 indent 分别影响什么

可以把两个参数拆开记：

例如设置 enc.Indent("XML: ", " ") 后，元素行会先出现 XML: ，再按照层级增加四个空格。prefix 不会被当成 XML 元素内容，它只是输出行的格式前缀；如果下游系统要求严格的无前缀文本，就把它设为空字符串。

使用 EncodeToken 时别忘了 Flush

Encode 和 EncodeElement 适合把一个值交给 Encoder，它们会在返回前调用刷新逻辑。需要逐个写开始标签、文本和结束标签时，通常会改用 EncodeToken，此时不要把“调用成功”误认为“底层 Writer 已经收到全部字节”。

func writeStream(w io.Writer) error {
    enc := xml.NewEncoder(w)
    enc.Indent("", "  ") // 先固定整个流的缩进策略

    tokens := []xml.Token{
        xml.StartElement{Name: xml.Name{Local: "message"}},
        xml.StartElement{Name: xml.Name{Local: "body"}},
        xml.CharData("hello"),
        xml.EndElement{Name: xml.Name{Local: "body"}},
        xml.EndElement{Name: xml.Name{Local: "message"}},
    }
    for _, token := range tokens {
        if err := enc.EncodeToken(token); err != nil {
            return err // 开始和结束元素不匹配时应立即停止
        }
    }
    return enc.Flush() // EncodeToken 不会替调用者自动 Flush
}

如果是长连接或分段输出，可以按业务边界调用 Flush，让已经写入的令牌尽快进入底层 Writer。但刷新不会替你补齐缺失的结束标签，元素配对仍然由代码负责。

结束流时用 Close 检查收尾状态

当 Encoder 不再写入时，调用 Close 比只调用 Flush 更适合作为最终收口。它会刷新缓冲的 XML，并在 XML 仍含未闭合元素等无效状态时返回错误。

func finishEncoder(enc *xml.Encoder) error {
    if err := enc.Flush(); err != nil {
        return err // 需要中途发送时，先处理底层 Writer 错误
    }
    if err := enc.Close(); err != nil {
        return err // Close 会检查是否存在未闭合的 XML 元素
    }
    return nil
}

如果前面的代码只使用 Encode 并且已经处理了它返回的错误，通常仍可以在生命周期结束处调用 Close，把“最终不再写入”表达清楚。对于直接使用 token 的代码，至少要保证最后一次 Flush 或 Close 被执行。

什么时候不应该强行加缩进

缩进主要服务可读性、日志排查和人工审阅。若 XML 文本节点中的空白本身有业务意义，或者下游按字节比较规范化结果，就要先确认新增换行和缩进不会改变消费方的语义。此时可以继续使用 Encoder，但不调用 Indent，或者把格式化输出与机器交换输出分成两条路径。

还要注意，Indent 只决定 Encoder 输出元素时的排版，不会替你修复不匹配的 token、选择 struct 字段映射，也不会把一段外部 XML 字符串自动美化。把职责边界分清，排查时就能判断问题是在数据模型、token 配对、Writer 错误，还是单纯的输出格式设置。

一张表记住流式 XML 的收尾顺序

一句话总结：先在 Encoder 上配置 Indent，再按你的写入方式选择 Encode 或 EncodeToken；token 流要主动 Flush，整个 XML 结束时用 Close 把缓冲和结构错误一起收口。

相关问题

Encoder.Indent 会改变 XML 数据内容吗？

它改变的是元素输出时的换行和缩进格式；如果消费方把文本节点中的空白当成数据，就应谨慎评估格式化输出。

为什么 EncodeToken 后缓冲区还是空的？

EncodeToken 不负责自动 Flush。直接使用 token 写流时，在需要发送或结束的位置显式调用 Flush，最后还要检查返回的错误。

只调用 Flush 能代替 Close 吗？

Flush 负责把缓冲内容写出，Close 还表达“不再写入”并检查未闭合元素。结束 Encoder 生命周期时优先调用 Close。