Go encoding/xml.Decoder 怎样保留错误信息

Go 的 encoding/xml.Decoder 不会把解析失败藏在结果对象里：Token、Decode 和 DecodeElement 都要检查返回的 error。最稳妥的做法是把 io.EOF 当作正常结束，把其他错误用 %w 包上业务上下文，再按 *xml.SyntaxError 等类型继续判断。

官方地址：https://pkg.go.dev/encoding/xml

Token 循环里先保留原始 error

流式解析最容易犯的错，是只处理 token、忽略第二个返回值，或者把所有错误都当成 EOF。官方语义是：输入耗尽时返回 io.EOF；标签不匹配、输入提前结束或读取失败时返回其他错误。下面的循环把这两个分支明确拆开。

package main

import (
    "encoding/xml"
    "fmt"
    "io"
)

func scanXML(r io.Reader) error {
    dec := xml.NewDecoder(r)
    for {
        tok, err := dec.Token()
        if err == io.EOF {
            // 输入正常结束，不把 EOF 当成解析失败。
            return nil
        }
        if err != nil {
            // Token 失败时保留原始错误，交给上层继续分类。
            return fmt.Errorf("读取 XML token 失败：%w", err)
        }
        _ = tok // 这里可以按 StartElement、CharData 等类型处理 token。
    }
}

不要只记录 err.Error() 后再返回一个新字符串。那样虽然日志里有文字，却失去了调用方用 errors.As 识别具体错误类型的机会。图片中的“错误链”是静态结构说明，不是某次程序运行的截图。

用 %w 包装错误，类型和上下文都留下

工程代码通常要补上文件名、消息编号或解析阶段，但包装时应使用 %w。这样日志能读懂，调用方仍可区分语法错误与其他输入错误。

package main

import (
    "encoding/xml"
    "errors"
    "fmt"
    "io"
)

func decodeConfig(r io.Reader) error {
    var cfg struct {
        Name string `xml:"name"`
    }
    dec := xml.NewDecoder(r)
    if err := dec.Decode(&cfg); err != nil {
        // Decode 的原始错误要通过 %w 继续向上传递。
        var syntaxErr *xml.SyntaxError
        if errors.As(err, &syntaxErr) {
            // SyntaxError 自带 Msg 和 Line，适合写入结构化日志。
            return fmt.Errorf("配置 XML 语法错误（第 %d 行）：%w", syntaxErr.Line, err)
        }
        if errors.Is(err, io.EOF) {
            // 空输入或提前结束另行处理，避免和语法错误混为一谈。
            return fmt.Errorf("配置 XML 没有完整内容：%w", err)
        }
        return fmt.Errorf("配置 XML 解码失败：%w", err)
    }
    _ = cfg
    return nil
}

SyntaxError.Line 是 XML 语法错误的行号；它解决的是解析层定位，不等于业务字段路径。若结构体标签冲突、字段类型不匹配或自定义 UnmarshalXML 返回错误，仍应保留原始 error 链，不能只按语法错误处理。

用位置与原始片段补齐排查上下文

InputPos 返回当前行和从 1 开始的列，InputOffset 返回流中的字节偏移。它们适合和错误一起写日志，但要注意：位置描述的是最近返回 token 的边界；错误发生时只能作为定位辅助，不能替代原始输入。

package main

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

func decodeWithContext(r io.Reader) error {
    var raw bytes.Buffer
    // TeeReader 保存已经读到的字节，适合小报文或受控长度的诊断缓存。
    dec := xml.NewDecoder(io.TeeReader(r, &raw))
    for {
        _, err := dec.Token()
        if err == io.EOF {
            // 所有 token 都已读完，返回成功。
            return nil
        }
        if err != nil {
            line, column := dec.InputPos()
            offset := dec.InputOffset()
            // 记录位置和已读取片段，但仍用 %w 保留根因。
            return fmt.Errorf("XML 解析失败 line=%d column=%d offset=%d raw=%q：%w", line, column, offset, raw.String(), err)
        }
    }
}

生产环境不要无上限保存原文：XML 可能来自用户上传或包含敏感字段。更稳妥的是限制缓存长度、做脱敏，或只记录偏移附近的片段。若错误发生在自定义 UnmarshalXML，在内部检查 DecodeElement 的返回值，再直接返回包装后的错误。

嵌套 DecodeElement 不要吞错

如果先用 Token 找到目标节点，再交给 DecodeElement 解析，嵌套调用的错误仍然属于同一条错误链。建议在节点名、消息编号等位置补充上下文，然后把错误返回到顶层统一记录。

func decodeItem(dec *xml.Decoder, start xml.StartElement) error {
    var item struct {
        ID string `xml:"id,attr"`
    }
    if err := dec.DecodeElement(&item, &start); err != nil {
        // 保留 DecodeElement 的原始错误，节点名只作为排查上下文。
        return fmt.Errorf("解析节点 %q 失败：%w", start.Name.Local, err)
    }
    _ = item
    return nil
}

这条边界很实用：DecodeElement 负责当前元素的结构化解码，顶层负责决定重试、丢弃、告警或返回 HTTP 错误。两层都返回 error，日志才能知道“哪一个节点”以及“为什么失败”。

常见问题

Token 返回 io.EOF 时需要记录错误日志吗？

完整输入正常读完时不需要。只有业务协议要求必须出现根节点，才应在循环外额外检查“是否见过根节点”。

fmt.Errorf 使用 %v 会怎样？

日志文本仍能显示，但错误链不会被 errors.Is 或 errors.As 继续识别。需要向上判断类型时使用 %w。

InputOffset 能精确指出坏字符吗？

它给出解码器当前位置的字节偏移，适合缩小范围；要展示原文，还要配合输入缓存，并考虑解码器缓冲和错误发生时机。

把 io.EOF、真实解析错误和业务上下文分开，Go encoding/xml.Decoder 的错误就不会在层层返回中丢失。对小报文保留受控原文，对大流只记录位置与脱敏片段，通常能在可诊断性和数据安全之间取得平衡。