Go encoding/xml Decoder.Strict 关闭后会改变什么

给 encoding/xml.Decoder 设置 Strict = false，并不是把 XML 解析器变成“什么都能吃”。它只放宽了几类常见输入错误：缺少结束标签时，解析器会为了让 token 保持平衡而补出结束标签；属性值和字符数据里的未知或格式错误实体会原样留下。默认的 Strict 是 true，因此生产代码应先确认上游数据确实带有 HTML 兼容或历史脏数据需求，再决定是否关闭。

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

先看 Strict 默认值和失败边界

最容易踩坑的是把“解析失败”与“结构不完整”混为一谈。下面的例子故意准备一个缺少 的输入，并在字符数据里放入未知实体。代码只用于展示对比路径，图示是静态结构示意，不代表本机运行截图。

package main

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

func readTokens(strict bool) {
    // 同一份输入只切换 Strict，便于定位参数真正改变的语义。
    input := `A&unknown;`
    d := xml.NewDecoder(strings.NewReader(input))
    d.Strict = strict
    for {
        tok, err := d.Token()
        if err == io.EOF {
            break
        }
        if err != nil {
            fmt.Printf("Strict=%v error=%v\n", strict, err)
            return
        }
        fmt.Printf("Strict=%v token=%T\n", strict, tok)
    }
}

func main() {
    readTokens(true)  // 严格模式优先报告不完整或不规范输入。
    readTokens(false) // 宽松模式允许部分常见错误继续进入 token 流。
}

严格模式下，未闭合元素可能在读到文档末尾前就报错；宽松模式则会补出缺少的结束 token，并把未知实体保留在字符数据中。这里的关键检查点不是“有没有报错”，而是下游是否能接受这棵被补齐的 token 结构。

理解 Strict=false 具体放宽了什么

Strict=false 的影响可以拆成三块，别把它们合并成一个笼统的“容错开关”。

尤其要注意第三行：官方说明明确指出，严格模式也不执行 XML 命名空间规范的全部要求，未识别前缀会被记录为名称空间 URL。因此，遇到命名空间问题时，先看 xml.Name.Space 和 Local，不要仅靠切换 Strict 判断输入是否可信。

这也解释了一个常见误解：宽松模式可能让 Decode 成功，并不代表原文符合 XML 规范，更不代表字段语义正确。成功只是说明解析器完成了它允许完成的 token 组织。

把 AutoClose 和 Entity 放回正确位置

如果目标是兼容典型 HTML，官方文档给出的组合是 Strict=false、AutoClose=xml.HTMLAutoClose、Entity=xml.HTMLEntity。三个设置各自负责一件事：

• Strict=false：允许前面说到的常见格式错误继续解析。
• AutoClose：指定哪些元素打开后，即使没有显式结束标签，也应立即视为关闭。
• Entity：把非标准实体名映射成字符串；内置映射始终包含 lt、gt、amp、apos 和 quot。

func htmlLikeDecoder(input io.Reader) *xml.Decoder {
    // 三项配置分工不同，缺少 Entity 不会自动获得 HTML 实体表。
    d := xml.NewDecoder(input)
    d.Strict = false
    d.AutoClose = xml.HTMLAutoClose
    d.Entity = xml.HTMLEntity
    return d
}

不要只写一行 d.Strict = false 就期待   等实体自动变成空格，也不要只配置 AutoClose 就认为所有非法结构都会被修复。实际项目可以先用一组固定样例分别覆盖标签、实体和命名空间，再决定组合配置。

在生产代码中选择解析策略

可以用下面的检查清单做决定：输入来自你能控制的 XML API 时，优先保持默认严格模式，让上游尽早修复；输入来自历史 HTML 片段或格式长期不稳定的合作方时，才考虑宽松模式，并把原始文本、来源和解析告警留在可追溯日志中。

1. 先确认问题类型：缺结束标签、异常实体，还是命名空间映射；不同问题不要用同一个开关处理。
2. 再确认消费方式：直接 Decode 到结构体时，补出的 token 可能改变字段边界；使用 Token 时要关注开始/结束元素是否仍符合业务规则。
3. 为每类脏输入保留回归样例，至少断言关键字段、元素层级和实体文本，而不是只断言 err == nil。
4. 把宽松解析限制在兼容边界内，后续仍做业务字段校验；解析成功不等于内容可信。

一句话判断：Strict=false 适合“我明确知道上游会缺什么，而且愿意定义补齐后的含义”的场景；不适合拿来掩盖未知来源的 XML 质量问题。

相关问题

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

不会。它只放宽部分常见错误；典型 HTML 兼容还需要按需设置 AutoClose 和 Entity。

为什么 Strict=false 后未知实体还没有被替换？

因为未知实体不会凭空获得含义。需要在 Decoder.Entity 中提供映射，否则它会按原文留在属性值或字符数据里。

命名空间前缀报错应该先关 Strict 吗？

不应直接这样做。先检查 xml.Name.Space、Local 和输入中的声明；Strict 本身并不负责执行命名空间规范的全部约束。