Go xml.Decoder 遇到不规范 XML 时怎么决定是否关闭 Strict

只有在来源明确、缺陷类型已知，而且业务接受解析器的容错解释时，才适合把 xml.Decoder.Strict 设为 false。它可以容忍某些缺失结束标签和不认识的字符实体，并不保证任意坏 XML 都能读完，更不保证读出的结构就是发送方本意。

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

先把兼容范围限制到具体来源

假设一个旧导出程序偶尔把 title 的结束标签漏掉，但外围 record 标签仍然存在。导入方可以要求来源修正，也可以为这个特定来源制定兼容规则。决定依据应是缺陷是否可解释、业务是否接受这种解释，而不是“关闭开关后没报错”。

如果所有输入都声称是规范 XML，默认严格解析更容易暴露生产方的问题。若确实存在固定旧格式，就把兼容选项放进该来源的导入配置，不要让一个历史例外悄悄改变所有入口。这里讨论解析兼容，不扩展 XML 外部实体或其他处理机制。

最小设置只改变当前 Decoder

NewDecoder 创建的解析器默认启用 Strict。最小兼容写法只需要改当前实例，并应在开始读取之前完成配置：

// 只为已明确允许兼容的输入创建实例，不改变其他解析入口。
dec := xml.NewDecoder(reader)
dec.Strict = false

关闭后，Token 可以在需要时补出结束标签，使返回的开始与结束标记保持平衡；属性值或文本中的未知、错误字符实体可以保留原样。注意“返回标记平衡”与“原文件没有缺陷”是两种结论。库帮助读取不规范输入，并没有把原始字节改写成一份新的规范文档。

例如未知的 &legacy; 保留下来，通常意味着文本里仍有这个字面片段，不代表它已经被翻译成你期望的字符。若该名字具有约定含义，应另外配置映射，而不是依赖猜测。

分别理解 Strict、Entity 和 AutoClose

旧 XML 的兼容问题并不意味着输入就是 HTML。不要把 HTMLAutoClose、HTMLEntity 整套复制进普通业务 XML。尤其是 AutoClose 会影响元素归属：如果业务元素本来应该包含子节点，却被指定为立即关闭，后面的数据所属位置就可能改变。

字符编码问题也应另行定位。声明使用非 UTF-8 编码的输入涉及 CharsetReader 等字符集处理；Strict=false 不是编码转换器。开关没有解决当前错误时，应保留具体消息继续分析，而不是再添加一组无关选项。

解析成功也要核对字段含义

解析结果可用，至少包含两层意思：库能够读取，以及业务字段仍符合预期。前者不会自动证明后者。对历史导入，应保留来源标识与原始文件，明确必填字段、允许的层级和缺失字段的处理方式。缺少 title 与 title 内出现未知实体，不应被压缩成同一种“导入成功”。

Strict=true 也不是业务模式检查器。它不替你保证 record 一定有编号、数量一定是整数，或某个元素只出现一次。标准库对命名空间也有其文档说明的限制，不能把 Strict 名称理解为对所有 XML 相关规范的完整验证。

因此可以采用“来源规则决定解析模式，业务规则决定是否接收结果”的分工。容错读出来后仍缺关键字段，就返回业务错误，而不是为提高导入数量直接提交。这是导入程序的设计要求，不需要把库的容错能力说成万能修复。

错误重试必须使用新的输入流

严格解析失败时，Reader 通常已经被消费了一部分。如果产品明确允许再试兼容模式，应重新打开文件或从保留的原始字节创建新 Reader，再创建新 Decoder。直接在失败实例上改 Strict 并继续读，不是从头重新解释同一输入。

也不要对所有错误无条件重试。读取失败、编码问题、业务字段错误各有处理方向；兼容入口应由已经识别的来源契约控制。生产方正在修复时，可以保留严格错误信息帮助定位，而不必让失败详情在兼容成功后完全消失。

用完整示例比较严格与兼容模式

下面用 Token 遍历比较两个固定文本样本，每种模式都独立创建输入流。示例只收集非空文本，用于展示解析选项差异，不冒充完整业务导入器；代码未在本文制作中执行。

package main

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

// collect 每次创建新 Reader，错误时不交付部分文本。
func collect(source string, legacy bool) ([]string, error) {
    dec := xml.NewDecoder(strings.NewReader(source))
    dec.Strict = !legacy
    var text []string
    for {
        tok, err := dec.Token()
        if tok != nil {
            if data, ok := tok.(xml.CharData); ok {
                s := strings.TrimSpace(string(data))
                if s != "" { text = append(text, s) }
            }
        }
        if err != nil {
            if errors.Is(err, io.EOF) { return text, nil }
            return nil, fmt.Errorf("读取 XML: %w", err)
        }
    }
}

func main() {
    // 两个样本各体现一种兼容情形，不把容错当成原文修复。
    samples := []string{
        "",
        "",
    }
    for _, source := range samples {
        for _, legacy := range []bool{false, true} {
            values, err := collect(source, legacy)
            fmt.Printf("兼容=%v 文本=%q 错误=%v\n", legacy, values, err)
        }
    }
}

第一个样本缺 title 的结束标签，第二个包含没有定义的实体名。按兼容规则，宽松模式可以对这些情形作容错处理；严格模式会报告相应语法问题。函数遇到非 EOF 错误返回 nil，避免调用方误用前面收集到的部分文本。

循环先处理非 nil token，再判断 err，遵循 Token 可能同时交付标记与错误的接口边界。若处理器要把 token 保存到后面使用，还要理解标记数据的生命周期；这里立即转成 string 并追加，不保留临时字节切片。

关闭 Strict 后仍然报错正常吗？

正常。它只放宽特定语法情形，不会消除所有词法、字符编码或底层读取问题。查看原始错误，不要把剩余错误解释为开关没有生效。

读出文本后再写回，能当作修复原文件吗？

不能仅凭本例下结论。文本收集本身会丢掉结构，容错后的结构也可能与原意不同。需要输出新文件时，应先定义业务模型与转换要求。

资料：Decoder 配置文档、XML 解析实现。