Go xml.Decoder.Strict 怎样兼容不规范 XML 输入

上游 XML 如果偶尔缺少结束标签、带有未声明的实体，直接使用默认的 encoding/xml.Decoder 往往会在解析阶段报错。处理这类输入时可以把 Decoder.Strict 设为 false，但它只是放宽 XML 语法的一小部分，不是“任何脏数据都能读”的开关。

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

先确认 Strict 放宽了哪些 XML 错误

xml.NewDecoder 创建的解码器默认启用严格模式。严格模式适合格式由自己控制的 XML：标签必须成对出现，实体需要符合规则，解析错误应尽早暴露。

把 Strict 设为 false 后，官方文档明确支持两类常见容错：元素缺少结束标签时，解析器可以补出结束标签；属性值和字符数据中的未知或畸形实体会原样保留。这个行为适合接收历史系统导出的“近似 XML”，但也意味着错误输入可能继续向下游传递。

把宽松解析配置放在输入边界

一个更稳妥的做法是只在“已知来源的兼容入口”关闭严格模式，并把配置写在创建 Decoder 的地方。对 HTML 风格输入，可以再给出要自动闭合的元素集合；对实体，则只映射业务确实允许的名称。

package main

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

func readLooseXML(data string) ([]xml.Token, error) {
    decoder := xml.NewDecoder(strings.NewReader(data))
    decoder.Strict = false // 允许缺少结束标签和畸形实体继续进入 Token 层
    decoder.AutoClose = xml.HTMLAutoClose // 仅对类似 HTML 的元素启用自动闭合
    decoder.Entity = xml.HTMLEntity // 只补充明确的 HTML 实体映射

    var tokens []xml.Token
    for {
        token, err := decoder.Token()
        if err == io.EOF {
            return tokens, nil // 读到结尾，说明 Token 层没有继续报错
        }
        if err != nil {
            return nil, fmt.Errorf("读取 XML token 失败: %w", err) // 保留底层错误原因
        }
        tokens = append(tokens, xml.CopyToken(token)) // Token 数据可能复用内部缓冲区
    }
}

这里的三个设置不是同一件事：Strict 决定是否放宽部分 XML 语法，AutoClose 决定哪些元素可以在打开后立即视为结束，Entity 决定额外的实体名称如何映射。不要为了“尽量读出数据”把三者无条件打开。

把容错解析和业务校验分开

解析成功只代表输入能被拆成 XML token，不能说明业务对象完整。比如订单 XML 缺少 id，或者金额字段虽然存在但不是合法数字，encoding/xml 不会替你完成业务规则判断。

type Order struct {
    ID    string `xml:"id"`
    Total string `xml:"total"`
}

func validateOrder(order Order) error {
    if order.ID == "" {
        return fmt.Errorf("订单缺少 id") // 容错解析后仍要检查关键字段
    }
    if order.Total == "" {
        return fmt.Errorf("订单缺少 total") // 业务必填项不能由 Strict 代替校验
    }
    return nil
}

建议把流程拆成“读取输入—解析 token 或结构体—校验必填字段—进入业务处理”四层。这样即使为了兼容历史数据关闭了 Strict，后面仍然有明确的拒绝边界。

用错误分层决定是否回退

排查时不要只看“Strict 改成 false 后能不能返回对象”，而要先确定错误属于哪一层：

• 实体层：未知实体可能被原样保留；如果业务不接受字面量 &name;，需要在业务层明确拒绝或清洗。
• 结构层：缺少结束标签可能被补齐，但意外的结束标签、无法组成合法 token 的内容仍可能失败。
• 字符集层：输入声明为非 UTF-8 时，使用 CharsetReader 接入转换器；Strict 不负责改变字节编码。
• 业务层：字段缺失、值域不合法、重复订单等问题必须由结构体校验或业务规则处理。

生产入口可以采用一个简单策略：默认严格解析；只有来源已经确认存在固定兼容问题时，针对该来源启用宽松模式，并把来源标识、解析模式和错误层级写入日志。这样后续仍能统计“容错了多少条”，而不是让脏数据无声通过。

常见问题

Strict=false 能解析所有不规范 XML 吗？

不能。它只放宽文档列出的常见错误，仍可能因为意外结束标签、无法识别的字节或其它结构问题返回错误。

AutoClose 和 Strict 是不是二选一？

不是。AutoClose 只在 Strict=false 时参与元素自动闭合规则；是否启用要由输入是否接近 HTML 风格决定。

为什么解析成功后还要做字段校验？

因为 XML 语法正确与业务数据完整是两件事。宽松解析解决输入边界问题，必填字段、数值范围和权限关系仍需业务代码确认。

可以把最终检查压缩成四个问题：这个来源是否真的需要宽松模式？允许哪些自动闭合元素？未知实体是否能进入业务数据？解析成功后由谁校验字段和回滚？这四项都有答案时，Strict=false 才适合进入生产配置。