Go xml.CharData 复用切片时为什么保存的文本会被改写

在 Go 里手动遍历 encoding/xml.Decoder.Token 时，xml.CharData 不能默认当成一份已经归调用方所有的字节。官方文档明确说明，Token 返回的字节切片引用解析器内部缓冲区，只保证到下一次调用 Token 之前有效。因此，把 CharData 直接 append 到结果切片，后面读到的新文本可能覆盖之前看到的内容。需要跨越下一次 Token 保存时，使用 data.Copy()、转换成 string，或按完整 Token 使用 xml.CopyToken。

CharData不是拥有者：问题究竟在哪

CharData 的定义本身就是 type CharData []byte。切片值只包含指针、长度和容量，复制这个切片值不会复制底层字节。更容易忽略的是，Decoder.Token 返回的相关字节来自解析器内部缓冲区，下一次取 Token 时，解码器可以重置并复用这块空间。

典型风险写法如下。这里的 saved 保存的是切片描述符，不是每次文本的独立副本；循环继续调用 Token 后，旧项的底层数据就可能被覆盖。

package main

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

func main() {
    input := `GoXML`
    decoder := xml.NewDecoder(strings.NewReader(input))
    var saved []xml.CharData

    for {
        token, err := decoder.Token()
        if err == io.EOF {
            break // 读完 Token 流后正常结束。
        }
        if err != nil {
            log.Fatal(err) // 语法错误不能当成普通文本继续处理。
        }
        if data, ok := token.(xml.CharData); ok {
            saved = append(saved, data) // 这里只复制了切片头，未复制底层字节。
        }
    }

    for _, data := range saved {
        fmt.Printf("%q\n", data) // 旧项可能已经看到后续 Token 写入的内容。
    }
}

这不是 XML 文本被“自动改写”，而是调用方继续持有了一个借用缓冲区的视图。具体显示结果会受文本长度、缓冲区容量和后续 Token 形状影响，所以不能靠一次输出碰巧正确来证明保存方式安全。

先把文本复制成快照，再离开 Token 循环

如果业务只需要元素里的文字，最小修复是在保存点建立副本。CharData.Copy 返回一份新的 CharData，语义最直接；如果后续只按文本处理，转成 string 也能得到稳定的字符串值。

if data, ok := token.(xml.CharData); ok {
    snapshot := data.Copy() // 复制底层字节，快照不再依赖 Decoder 的缓冲区。
    saved = append(saved, snapshot)
}

// 如果结果模型只需要文本，可以直接保存字符串。
if data, ok := token.(xml.CharData); ok {
    texts = append(texts, string(data)) // 转成字符串后按文本值保存。
}

判断标准很简单：当前分支处理完就丢弃的 data 可以直接读；要放进切片、交给 goroutine、缓存到结构体，或者等循环结束再处理，就应先复制。复制应尽量靠近“所有权转移”的位置，否则后面某个辅助函数很容易忘记生命周期限制。

按用途选择复制方式：文本、字节还是完整 Token

完整 Token 不只有 CharData。StartElement 的属性切片、Comment、Directive 等也可能包含字节数据。要把 Token 放入队列或跨 goroutine 传递，使用 xml.CopyToken(token) 比只对某一种类型做断言更稳妥。

copied := xml.CopyToken(token) // 按 Token 类型复制内部字节和属性切片。
queue = append(queue, copied)

// 只对当前 CharData 做字节级快照时，也可以使用 bytes.Clone。
if data, ok := token.(xml.CharData); ok {
    raw := bytes.Clone(data) // 返回独立的 []byte，便于后续修改或异步处理。
    consume(raw)
}

空白、实体和 Unmarshal：不要把三个问题混在一起

CharData 表示 XML 字符数据，实体会按解析规则转换成对应字符；它不是原始 XML 片段。缩进换行也可能作为字符数据 Token 出现，通常应先判断是否为空白，再决定是否保存。

if data, ok := token.(xml.CharData); ok {
    text := strings.TrimSpace(string(data)) // 先转为稳定文本，再决定是否忽略缩进。
    if text == "" {
        continue // 纯格式化空白不进入业务结果。
    }
    values = append(values, text)
}

手动 Token 循环与 xml.Unmarshal 也要分开判断。结构体反序列化会把字符数据映射到带 xml:",chardata" 标签的字段；题目中的覆盖风险针对的是你自己从 Decoder.Token 取出并跨调用保存借用切片的场景。看到文本异常时，先确认调用路径，再检查是否把切片头当成了字节副本。

常见问题

只把 CharData 放进 interface{}，还会被覆盖吗？

会。接口只是包住了 CharData 这个切片值，不会替你复制底层数组；跨越下一次 Token 前仍要调用 Copy 或转成字符串。

当前循环里马上调用 string(data)，还需要 Copy 吗？

如果字符串值就是最终结果，通常不需要再调用 Copy；关键是不要保存原始 CharData 以为它代表独立字节。字符串快照应在下一次 Token 前完成。

xml.CopyToken 能解决所有 XML 数据复用问题吗？

它用于复制 Token 中的字节切片和属性切片，适合 Token 队列或异步处理；它不会替你设计字段清洗、空白过滤或 XML 业务校验规则。

记住一条边界即可：Decoder.Token 给你的部分字节是临时借用，当前调用内消费可以，跨调用保存必须复制。把复制动作放在数据进入缓存、队列或业务结构体的那一刻，最不容易留下隐蔽的生命周期 bug。