Go XML Decoder Strict 关闭后适合什么兼容场景

Go 的 xml.Decoder.Strict 默认为 true。关闭后适合边界明确的旧 XML-like 数据兼容，例如容忍部分缺失结束标签，或让未知、格式不正确的字符实体留在文本里；它不是“任何坏 XML 都能修复”的开关，也不保证解析得到的结构符合业务原意。

如果我要迁移一批旧导出文件，我会先用有限样本弄清每种容错的含义，再考虑单独设置兼容入口，而不会把所有 XML 读取都改成宽松模式。下面是这种选择的示例，没有虚构旧系统事故或实际迁移结果。

官方文档：https://pkg.go.dev/encoding/xml#Decoder；解析器源码：https://go.dev/src/encoding/xml/xml.go。

我会把宽松模式当迁移工具，而不是正常输入默认值

旧导出程序可能生成 缺失结束标签，也可能把 未知实体 原样写入内容。严格模式能暴露这些问题，宽松模式则可能继续生成 Token。我的取舍是：正式接口保持预期输入规则，只有明确接受这些历史偏差的迁移入口才考虑 Strict=false。

接受某一种偏差，需要知道它对字段含义有何影响。例如文本里保留 &vendor;，不等于它已经替换成供应商名称；标签补闭合后，也不能保证业务字段仍处于原作者想表达的层级。宽松解析更适合可人工回查的迁移材料，不适合作为数据正确性的证明。

准备三个小样本，看容错与失败分别在哪里

本例用三个原创字符串：第一个 feed 中的 name 没有正常闭合；第二个包含未定义的实体；第三个属性引号没有正常结束。分别新建 Decoder，以 strict=true 和 strict=false 读取完整 Token 流。选择 Token 而不是只 Decode 一次，是为了让样本后续读取中的错误也被观察到。

原始输入 由 Decoder 读取，Strict 决定部分容错行为，输出为 Token 或 解析错误。原始输入与 Token 是不同表示，解析器可能补出原文没有的结束标签。

把对照写成一个完整的小程序

将以下内容保存为 main.go。collect 在任何非 EOF 错误上返回错误，并放弃部分展示结果；这体现的是本文示例策略，不是 Decoder 自动提供事务提交功能。

package main

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

// collect 只处理本文的小样本，遇到错误不提交部分结果。
func collect(input string, strict bool) ([]string, error) {
    d := xml.NewDecoder(strings.NewReader(input))
    d.Strict = strict
    var items []string
    for {
        token, err := d.Token()
        if err == io.EOF {
            return items, nil
        }
        if err != nil {
            return nil, fmt.Errorf("offset=%d: %w", d.InputOffset(), err)
        }
        switch t := token.(type) {
        case xml.StartElement:
            items = append(items, "start:"+t.Name.Local)
        case xml.EndElement:
            items = append(items, "end:"+t.Name.Local)
        case xml.CharData:
            // 只用于展示文本，不声称每段 CharData 是业务字段。
            items = append(items, "text:"+string(t))
        }
    }
}

func main() {
    samples := []struct {
        name string
        input string
    }{
        {"missing-end", "legacy"},
        {"unknown-entity", "A &vendor; B"},
        {"broken-quote", ""},
    }

    for _, sample := range samples {
        for _, strict := range []bool{true, false} {
            // 每次新建 Decoder，避免复用已经消费过的流。
            items, err := collect(sample.input, strict)
            if err != nil {
                fmt.Printf("%s strict=%t error=%v\n", sample.name, strict, err)
                continue
            }
            fmt.Printf("%s strict=%t tokens=%q\n", sample.name, strict, items)
        }
    }
}

items 只是为了观察有限样本而保存的字符串列表；它丢弃属性、命名空间等细节，不是生产转换器，也不保存或重建原 XML。CharData 可能分成多个 Token，不能把“每一段文本”直接当作一个完整字段。

# 在空目录初始化示例模块，只需一次。
go mod init example.com/xml-compat
# 运行有限样本的两种解析配置。
go run .

以上命令供读者运行，本文没有执行它们。观察重点是成功与错误的分布，以及 Token 中 name 的结束标记和未知实体文本；不要求匹配某个固定报错字串或 Token 分段形式。第三种断裂属性输入并不会仅因 Strict=false 就成为有效内容。

补结束标签和保留实体，意味着什么

对缺失结束标签，宽松模式会按需要补出结束 Token，维持 Token 返回的配对关系。我认为最值得注意的不是“终于读完”，而是消费方可能看到了经过容错处理的结构。collect 只展示它，并没有猜出数据生产者的原始意图。

对未知或格式不正确的实体，宽松模式可让这些序列留在字符数据或属性值里，而不是保证解释成目标字符。若业务确实约定某个非标准实体，应明确配置 Entity 映射，不能用“没报错”当作已完成字符替换。

AutoClose 与 Entity 是独立配置。关闭 Strict 不会自动装入 HTMLAutoClose 和 HTMLEntity。文档给出的组合可处理典型 HTML，但不能把它扩大成浏览器级 HTML5 树构建行为或任意网页兼容承诺。若任务本身是 HTML，应根据该任务选择解析器，而不是让 XML 宽松配置承担全部职责。

真正接入时，我会保留这些限制

我会按来源显式选择模式，保留可回查的原始输入，并记录解析失败。不要在所有错误上无条件“严格失败就再宽松一次”，因为这会把意外损坏也混进已允许的兼容范围。即使使用宽松模式，每次 Token 返回的 error 都要处理。

能读成 Token 与业务可接受是两层判断：必填字段、数量范围、根元素要求和允许的命名空间需要按业务规则另外处理。Strict=true 也不是 XSD 校验器；文档还指出它不完整强制 XML 命名空间规范，对未定义前缀并不按完整命名空间校验器的方式拒绝。

字符集问题也不能靠关 Strict 解决。Decoder 默认按 UTF-8 处理输入；非 UTF-8 编码若需要转换，应按 CharsetReader 的约定另行安排。本文的小样本不涉及外部文件、网络下载、编码转换或无界大输入，不能直接当高容量生产导入方案。

哪些观察可以决定是否采用兼容入口

xml.Unmarshal 能直接设置 Strict 吗？需要控制 Decoder 配置时应自行创建 Decoder，再选择 Token 或 Decode 等读取方法；不要把配置设在一个没被使用的 Decoder 上。

宽松读完就能把原输入当标准 XML 保存吗？不能。补出的 Token 与原始字节不同，实体保留也不代表其符合标准；本文的展示列表更不是 XML 规范化器。

适合所有第三方接口吗？不适合。若接口约定是严格格式，我会优先让错误显露并修正来源；只有来源明确、偏差可描述、结果可回查的兼容任务，才考虑关闭 Strict。

对我而言，宽松模式的收益是让受控迁移多一种读取选择，代价是不能再把解析成功当原输入符合规范。把允许的偏差和不可接受的错误写清楚，比简单取消报错更重要。