Go encoding/xml调整 Decoder.Strict 处理坏 XML的容错方案

接收方 XML 经常不是教科书里的完整文档：上游可能漏掉结束标签，也可能把未知实体原样塞进字符数据。Go 的 encoding/xml.Decoder 默认是严格模式，优先保证输入结构可验证；如果业务明确要兼容这类历史数据，可以把 Strict 设为 false，再按数据形态决定是否配置 AutoClose 和 Entity。关键是把“容错解析”限制在边界内，不能把所有脏 XML 都静默当成正确数据。

官方文档：https://pkg.go.dev/encoding/xml

先区分：结构容错还是数据正确

Strict 默认值为 true。严格模式发现元素没有闭合，或者实体写法不符合 XML 规则时，会尽早返回错误；关闭后，解析器会为缺少结束标签的元素补出平衡的结束事件，并让未知或格式不正确的实体保持原样。

这种变化只解决“能否继续读取 token”的问题，不代表字段一定存在、金额格式一定正确，也不代表输入已经符合 XML 命名空间规范。建议把宽松 Decoder 放在兼容层，解析结束后仍使用必填字段、根元素和业务状态做二次判断。

按输入来源选择 Strict 的配置方式

不要修改全局配置，也不要为了让一次请求通过而长期关闭严格模式。为这一类来源创建独立 Decoder，并在日志中保留来源标识、解析模式和字节位置。下面的示例把宽松模式限定在一个函数中：

package main

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

type Feed struct {
    Item string `xml:"item"`
}

func decodeLegacy(data string) (Feed, error) {
    decoder := xml.NewDecoder(strings.NewReader(data))
    decoder.Strict = false // 允许兼容缺少结束标签和未知实体的历史输入

    var feed Feed
    if err := decoder.Decode(&feed); err != nil {
        return Feed{}, fmt.Errorf("解析兼容 XML 失败：%w", err)
    }
    if feed.Item == "" { // 宽松解析后仍检查业务必填字段
        return Feed{}, fmt.Errorf("item 为空")
    }
    return feed, nil
}

func main() {
    feed, err := decodeLegacy("A&legacy;")
    if err != nil && err != io.EOF { // 真实服务中应把错误交给调用方处理
        fmt.Println(err)
        return
    }
    fmt.Println(feed.Item)
}

示例中的 &legacy; 会作为未知实体保留，而不是自动变成某个字符。生产代码应根据协议决定是否接受它；如果后续要把字段写回标准 XML，必须先明确实体的转义策略，避免把兼容输入再次输出成不可解析内容。

AutoClose 与 Entity 什么时候值得配置

AutoClose 只有在 Strict=false 时才有意义。它列出一组“打开后即可视为关闭”的元素，适合接近 HTML 的输入，不适合随意套在订单、账单等层级敏感的 XML 上。元素一旦被提前关闭，后续 token 的嵌套关系就会按照这个规则变化。

Entity 用来补充非标准实体名称与字符串的映射。官方实现始终认识 lt、gt、amp、apos、quot 这些基础实体；业务扩展应采用白名单，而不是把任意输入转换成可执行或不可见字符：

decoder := xml.NewDecoder(strings.NewReader(raw))
decoder.Strict = false // 兼容历史报文，但不放弃后续字段校验
decoder.AutoClose = []string{"br", "meta"} // 只列出协议明确允许自闭合的元素
decoder.Entity = map[string]string{
    "nbsp": " ", // 只映射协议中约定的实体
}

var doc Feed
if err := decoder.Decode(&doc); err != nil {
    return fmt.Errorf("读取报文失败：%w", err) // 保留原始错误供排查
}

如果输入只是标准 XML，保留默认严格模式更简单；如果它其实是 HTML 片段，最好先使用专门的 HTML 解析器。encoding/xml 的宽松开关是兼容手段，不是 HTML 语法的完整实现。

用结果和边界做最后决策

排查“关闭 Strict 后仍然失败”时，先看是否是编码、根元素、字段类型或业务校验错误，再检查 AutoClose 是否改变了层级。可以结合 Decoder.InputOffset 定位字节位置，但不要把宽松解析当成数据清洗的替代品。

常见问题

Strict=false 会自动修复所有坏 XML 吗？

不会。它主要覆盖缺失结束标签和部分实体容错；编码错误、严重的词法错误、字段转换失败以及业务规则错误仍可能返回错误。

AutoClose 和 Strict=false 可以只配置一个吗？

AutoClose 只在宽松模式下参与处理，所以通常需要先关闭 Strict；但是否配置 AutoClose 仍取决于输入协议，不应为了“少报错”而随意增加元素。

实际项目中，最稳妥的方案是严格模式优先、兼容模式隔离、容错后复查。这样既能接住旧 XML，又不会让一次成功解码掩盖数据结构已经变坏的事实。