Go xml.Decoder.Strict 关闭后会容忍哪些格式问题

把 xml.Decoder.Strict 设为 false 后，Go 主要会容忍并修补缺失或错配的结束标签，同时把未知或写坏的字符实体留在文本中。标准库源码还会在非严格模式下接受没有引号的属性值，以及没有等号的属性。它并不是“忽略所有 XML 错误”：非法名称、错误的声明与指令、损坏的 CDATA 或注释、非法字符等仍可能返回错误。

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

Strict=false 是兼容固定历史来源的解析策略，不是清洗器、安全过滤器或业务校验器。对公网或未知来源 XML 直接关闭 Strict，等于主动放弃一部分格式保证。

Strict 关闭后到底放宽了什么

默认情况下 Decoder.Strict 为 true。严格模式要求开始标签和结束标签正确嵌套，也要求实体引用满足 XML 规则。关闭后，解析器会尝试维持 Token 输出的标签平衡，而不是遇到第一处常见格式问题就停止。

最容易被忽略的是“自动平衡”带来的信息损失。假设上游发送 A，严格模式会把错配当作语法错误；非严格模式可能先补上 ，再关闭 order。解析成功只说明标准库构造了平衡的 Token，不等于原始文档结构正确。

哪些问题仍然会报错

关闭 Strict 不会把解析器变成“任何文本都收”。不支持的 XML 版本、非法标签名、损坏的 CDATA、注释或处理指令、禁止出现在文本中的控制字符，以及无法按字符集读取的内容，仍可能让 Decode 或 Token 返回错误。

还有两类边界不能只看 Strict：

• 字符编码：Decoder 假设输入是 UTF-8。XML 声明指定其他编码时，需要配置 CharsetReader；否则解析会停止。
• 命名空间：encoding/xml 即使在严格模式下也不完整执行 XML Namespaces 规范。未定义前缀不会因此被拒绝，前缀可能直接记录到名称的命名空间字段里，所以 Strict 不能替代命名空间白名单。

xml.Unmarshal 内部创建 Decoder，却没有参数让调用方关闭 Strict。需要容错时应显式使用 xml.NewDecoder，这样设置位置、来源和责任边界都清楚。

AutoClose 和 Entity 不是自动开启

AutoClose 与 Entity 是两个独立字段。只有 Strict=false 时，AutoClose 列表才允许把指定元素视为打开后立即关闭；Entity 则负责把额外实体名映射为替换文本。单独关闭 Strict，不会自动启用 xml.HTMLAutoClose 或 xml.HTMLEntity。

dec := xml.NewDecoder(r)
dec.Strict = false // 允许已知的历史 HTML 风格输入。
dec.AutoClose = xml.HTMLAutoClose // 显式启用常见 HTML 自动闭合规则。
dec.Entity = xml.HTMLEntity // 显式启用标准库提供的 HTML 实体表。

这组配置适合处理受信任的旧 HTML 片段，不应无条件套在普通 XML 接口上。XML 本身始终认识 lt、gt、amp、apos 和 quot 五个预定义实体；其他名称只有出现在 Entity 映射里才会被替换。来源自定义实体时，使用来源专用的小映射比直接启用完整 HTML 表更容易审计。

把宽松解析放在输入边界

保护的资产不是“是否返回 nil error”这么简单，而是字段归属、结构含义、审计位置和拒绝异常输入的能力。适合关闭 Strict 的场景通常同时满足：来源固定、格式缺陷已知、输入大小受限、字段有业务约束、失败可定位。

输入大小限制要在解码前完成。直接把 io.LimitReader 交给非严格 Decoder 有一个隐患：达到上限后表现为 EOF，而 Strict=false 恰好可能给被截断的 XML 补结束标签。下面先读取 max+1 字节并拒绝超限，再开始解析。

package partnerxml

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

type Feed struct {
    ID string `xml:"id"`
}

func DecodeFeed(r io.Reader, max int64) (Feed, error) {
    // 多读一个字节，用于区分“刚好达到上限”和“已经超限”。
    limited := &io.LimitedReader{R: r, N: max + 1}
    data, err := io.ReadAll(limited)
    if err != nil {
        return Feed{}, fmt.Errorf("读取 XML 失败: %w", err)
    }
    if int64(len(data)) > max {
        return Feed{}, errors.New("XML 超过大小上限")
    }

    dec := xml.NewDecoder(bytes.NewReader(data))
    dec.Strict = false // 只为该固定来源兼容已知格式缺陷。

    var out Feed
    if err := dec.Decode(&out); err != nil {
        line, column := dec.InputPos() // 记录解析停止附近的位置。
        return Feed{}, fmt.Errorf("XML 在 %d:%d 解析失败: %w", line, column, err)
    }
    if strings.TrimSpace(out.ID) == "" {
        return Feed{}, errors.New("缺少必填字段 id")
    }
    return out, nil
}

对流式超大文档，可以设计带计数和明确“超限”错误的 Reader，但目标仍是避免把限制触发伪装成普通 EOF。解析成功后还要验证必填字段、枚举值、数量、层级和跨字段关系；否则错配标签造成的字段漂移可能悄悄进入数据库。

记录位置与业务校验

Decoder.InputPos 返回最近一个 Token 末尾对应的行列位置，InputOffset 返回当前输入流的字节偏移。它们适合写入内部审计记录，帮助识别是哪一批、哪个来源、哪个位置触发了拒绝。日志中不要直接打印整份原始 XML，因为其中可能包含账号、订单或个人信息。

何时不该关闭 Strict

如果系统需要验证签名原文、依赖精确节点边界、执行安全敏感配置、接收公网输入，或者无法说明上游究竟有哪些固定缺陷，就不应关闭 Strict。先让严格模式暴露问题，再推动上游修复，通常比在所有入口永久容错更安全。

即使保持 Strict=true，也不能把它当作 XML Schema、命名空间规范或业务规则验证器。严格模式提供的是一组语法保证；字段是否允许、数量是否合理、命名空间是否可信、数据是否授权，仍由应用负责。

常见问题

Strict=false 会自动识别所有 HTML 实体吗？

不会。未知实体会被保留为原始文本。需要 HTML 实体时必须显式设置 dec.Entity = xml.HTMLEntity，更稳妥的做法是为固定来源配置最小映射。

Strict=false 能处理所有缺失结束标签吗？

它会按需补出结束标签，以维持 Token 平衡，但这只是解析器的修补结果。截断输入或错配结构可能因此被接受，业务层仍要验证文档完整性和关键字段。

为什么已经关闭 Strict，非 UTF-8 XML 仍然失败？

字符编码处理由 CharsetReader 负责，与 Strict 的标签和实体容错不是同一件事。XML 声明指定其他编码而没有 CharsetReader 时，Decoder 会返回错误。

可以用 xml.Unmarshal 开启宽松模式吗？

不可以直接设置。需要创建 xml.NewDecoder，设置 Strict=false，再调用 Decode。

结论

xml.Decoder.Strict=false 的核心作用是兼容常见的标签、实体和属性格式缺陷：补缺失结束标签、修复错配、保留未知实体，并接受部分 HTML 风格属性。它不会自动开启 AutoClose 或 HTML 实体表，也不会消除字符编码、非法结构和业务数据错误。最可靠的用法，是把它限制在固定来源入口中，先拒绝超大输入，再显式配置实体与自动闭合规则，最后用字段校验和位置审计收住容错带来的不确定性。