Go xml.Decoder 设置 Strict=false 后哪些输入仍然不能解析

接手一段不稳定的 XML 导入代码时，最容易产生的误解是：把 Decoder.Strict 设为 false，所有“看起来像 XML”的文本就都能读进来。实际情况更窄：它主要放宽缺少结束标签、部分字符实体和局部标签闭合问题；输入如果连基本 token 都无法形成，或者编码、命名空间和文档边界出了问题，解析仍会失败。

判断 Strict=false 是否有用，先问“这是可恢复的结构小错，还是无法切词的语法/编码错误”。前者可以兼容，后者必须修复输入或显式转换。

先看懂 Strict=false 究竟放宽了什么

xml.NewDecoder 创建的解码器默认是严格模式。关闭后，遇到一个开始标签没有对应结束标签时，Token 可以补出结束节点，让返回的开始、结束元素保持平衡；属性值和字符数据中的未知或格式不良实体，也可以原样留下。这个行为适合读取来源不稳定、接近 HTML 的数据，但它不是 XML 清洗器。

即便把 Go 标准库 xml.Decoder 的 Strict 字段设置为 false，也只能跳过部分 XML 语法校验，不少存在底层格式错误、语义冲突、编码违规的输入依然会直接抛出解析错误，没法正常把数据映射到结构体中。

package main

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

func main() {
    input := `文本 &broken`
    d := xml.NewDecoder(strings.NewReader(input))
    d.Strict = false // 只打开有限容错，不代表任意损坏输入都能解析

    for {
        token, err := d.Token()
        if err == io.EOF {
            break // 正常读完输入
        }
        if err != nil {
            fmt.Println("解析失败:", err)
            break // 记录错误，避免把不完整结果当成成功
        }
        fmt.Printf("%T: %v\n", token, token)
    }
}

示例中的 &broken 不会因为名字陌生就自动变成某个字符；如果业务需要 HTML 风格实体，应另行设置 d.Entity。同样，缺少结束标签被补齐，只代表 token 流能继续走，不代表原始文档已经合规。

哪些输入仍然会在解析阶段失败

第一类是连标签或属性都无法切出来的损坏。例如开始标签写到一半就结束、属性值使用引号却没有闭合、注释或 CDATA 起始标记没有对应结尾。这些问题发生在生成 token 之前，Strict=false 没有足够信息去推断原意。

第二类是没有可匹配父节点的结束标签，例如文档直接出现 。宽松模式可以对某些局部名称不一致的闭合做恢复，但没有任何已打开元素时仍是意外结束标签，不能当作正常节点交给 Decode。

第三类是命名空间不一致。未声明的前缀在 Token 中可能被记录为未知空间，但开始元素和结束元素的命名空间不同，仍然属于结构错误。不要把“忽略命名空间声明”误解成“允许任意命名空间混用”。

用四个字段把问题分层定位

AutoClose 只在非严格模式下把指定元素视为立即闭合，常见于类 HTML 输入；它不会修复任意嵌套关系。Entity 可以增加非标准实体映射，但内置的五个 XML 基本实体仍按标准处理。若输入声明了其他字符集，CharsetReader 必须返回非空的转换 reader，否则解码会以错误结束。

func decodeXML(data string) error {
    d := xml.NewDecoder(strings.NewReader(data))
    d.Strict = false // 兼容有限的脏输入
    d.Entity = map[string]string{"nbsp": " "} // 只声明业务确认过的实体

    for {
        _, err := d.Token()
        if err == io.EOF {
            return nil // 完整消费 token 后才算成功
        }
        if err != nil {
            line, column := d.InputPos() // 记录失败附近的行列
            return fmt.Errorf("XML 第 %d 行第 %d 列: %w", line, column, err)
        }
    }
}

把宽松解析放在正确的业务边界

配置文件、权限、账务或需要严格校验的接口，通常应保留默认严格模式，并把错误返回给上游。只有在确实面对历史 XML、抓取片段或类 HTML 数据时，才考虑 Strict=false；同时保存原文摘要、解析告警和缺失字段，避免“解析成功”掩盖数据被补齐或实体被保留的事实。

最终检查可以按这个顺序执行：先确认字符集，再确认是否能持续返回 token；发现缺失闭合时判断是否允许恢复；遇到实体时核对映射；最后用 InputPos 或 InputOffset 记录失败点。这样定位出来的才是“Strict 放宽范围之外的真实问题”。

常见问题

Strict=false 会自动把 XML 当 HTML 解析吗？

不会。要接近 HTML 的效果，通常还要配合 AutoClose 和 HTMLEntity；而且这仍是有限的 token 容错，不是完整 HTML 解析器。

未知实体会直接报错吗？

严格模式下通常会报错；非严格模式下，在属性值和字符数据中的未知或格式不良实体可以被保留。业务若需要字符替换，应显式维护映射并测试数据语义。

为什么少一个结束标签能成功，少一个属性引号却失败？

前者还能形成开始元素，解码器有机会补一个结束节点；后者破坏了属性值的词法边界，连合法 token 都不一定能产生，所以不能简单靠 Strict=false 推断。