Go encoding/xml用 Token 读取混合内容的解析方法

我第一次用 Go 处理带富文本字段的 XML 时，直接把目标结构体交给 Unmarshal，结果正文里的内嵌标签和文本顺序很难保留下来。需要读取“普通文本 + 子标签 + 普通文本”这种混合内容时，更稳的办法是用 encoding/xml.Decoder.Token 逐个消费事件：遇到开始标签进入层级，遇到 CharData 收集文字，遇到结束标签退出层级。

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

把混合内容拆成可观察的 XML 事件

假设输入是一个文章摘要，正文中夹着加粗词和强调词。Token 不会直接给出“最终摘要”，而是按 XML 流的顺序返回 token。这个特性正好适合边读边处理，也避免把整份 XML 一次性加载到内存。

package main

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

func main() {
	input := `
先看 关键结论，再看 边界。
`
	decoder := xml.NewDecoder(strings.NewReader(input))

	for {
		token, err := decoder.Token()
		if err == io.EOF {
			// EOF 表示输入正常结束，不是解析失败。
			break
		}
		if err != nil {
			// 其他错误可能来自格式损坏或底层 Reader，必须停止继续消费。
			panic(err)
		}

		switch value := token.(type) {
		case xml.StartElement:
			// 开始标签提供当前层级和属性信息。
			fmt.Println("start:", value.Name.Local)
		case xml.CharData:
			// 字符数据可能被多个内嵌标签分割，不能假设只有一段。
			fmt.Printf("text: %q\n", string(value))
		case xml.EndElement:
			// 结束标签用于退出当前层级，和开始标签成对出现。
			fmt.Println("end:", value.Name.Local)
		}
	}
}

这里最容易误判的是 CharData。它只代表当前读到的一段字符数据，前后可能分别属于同一个目标节点；换句话说，文本被子标签打断是正常情况，不能用一次读取结果代替完整字段。

用元素栈把文本归并回目标字段

真正写业务代码时，我会维护一个元素栈和一个文本缓冲区。只有栈顶路径位于 summary 内时才收集文字；进入 strong 或 em 只改变层级，不改变“仍属于摘要”的判断。

type mixedText struct {
	path  []string
	parts []string
}

func readSummary(decoder *xml.Decoder) (string, error) {
	var result mixedText
	insideSummary := false

	for {
		token, err := decoder.Token()
		if err == io.EOF {
			// 调用方应把正常结束和截断错误区分开。
			return strings.Join(result.parts, ""), nil
		}
		if err != nil {
			// XML 不完整时不要返回看似成功的半截正文。
			return "", err
		}

		switch value := token.(type) {
		case xml.StartElement:
			result.path = append(result.path, value.Name.Local)
			if value.Name.Local == "summary" {
				// 进入目标节点后再开始收集混合文本。
				insideSummary = true
			}
		case xml.CharData:
			if insideSummary {
				// 保留原始顺序；是否压缩空白交给业务规则决定。
				result.parts = append(result.parts, string(value))
			}
		case xml.EndElement:
			if value.Name.Local == "summary" {
				// 结束目标节点后停止接收兄弟节点的文本。
				insideSummary = false
			}
			result.path = result.path[:len(result.path)-1]
		}
	}
}

示例只演示一个目标节点，因此用布尔值就够了；如果 XML 允许嵌套同名 summary，应改成按栈深度判断。属性则从 xml.StartElement.Attr 读取，和文字缓冲区分开保存，不要把属性内容误拼进正文。

连续 CharData 和空白要按业务语义处理

混合内容的结果是否需要保留空格，取决于字段用途。面向展示的摘要通常要保留“关键结论”和“边界”之间的分隔；面向索引的纯文本字段，才可能统一折叠连续空白。建议先保存原始片段，再在最后一步做清洗，这样排查标签边界时还有依据。

用错误边界决定 Token 还是 DecodeElement

Token 的优势是控制细节和流式读取，但也意味着你要自己维护层级、空白和结束条件。如果某个子节点结构固定、只需要映射到结构体，可以在拿到对应的 StartElement 后调用 DecodeElement，不要为了所有 XML 都手写状态机。

• 正常结束：读取到 io.EOF，说明输入流已经完整消费。
• 格式错误：标签未闭合、嵌套不匹配等情况会返回错误，不能把已收集字符串当成完整结果。
• 流式边界：底层 Reader 可能在网络读取时返回错误；应保留错误并让上层决定重试或丢弃。
• 范围边界：遇到目标节点的结束标签后立即停止收集，避免把下一个兄弟节点内容混入。

相关问题

为什么一次 Token 读不到完整正文？

因为正文可能被子标签、实体或底层读取边界拆成多个 CharData。应在目标节点范围内按顺序追加片段，而不是只保留一次返回值。

什么时候直接用 DecodeElement？

当目标元素的结构稳定，且你只需要属性和字段映射时，DecodeElement 更省代码；需要保留混合文本顺序、筛选部分子节点或处理大流时，再选择 Token。

读取到 EOF 后还能继续调用 Token 吗？

不应把 EOF 当成还有数据的信号。循环在第一次收到 io.EOF 后结束，并把此前已经确认完整的结果交给调用方。

这类解析的关键不是把 XML 全部转成字符串，而是把“进入节点、看到文字、离开节点”分别处理。先限定目标路径，再合并连续字符数据，最后把 EOF、格式错误和底层读取错误分开，encoding/xml 的 Token 方式就能稳定应对混合内容。