Go csv.Reader.ReuseRecord 开启后为什么保存的行会被改写

在大 CSV 导入器里，ReuseRecord 很适合降低逐行读取时的切片分配，但它有一个容易被忽略的前提：Read 返回的记录切片只适合当前处理阶段。如果把它直接放进缓存或交给异步任务，下一次读取可能复用同一个底层数组，之前保存的“行”看起来就像被改写了。

问题通常不在字段字符串，而在保存了可复用的 []string 切片容器。需要跨越下一次 Read 保存时，先用 append([]string(nil), record...) 复制一份记录。

先把“被改写”这个现象复现出来

下面的导入器只做一件事：读取两行 CSV，并把每行放进 saved。代码里的注释说明了关键边界。

package main

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

func main() {
    input := "id,name\n1,Ada\n2,Linus\n"
    reader := csv.NewReader(strings.NewReader(input))
    reader.ReuseRecord = true // 允许连续 Read 复用记录切片的底层数组

    var saved [][]string
    for {
        record, err := reader.Read()
        if err == io.EOF {
            break
        }
        if err != nil {
            panic(err) // 解析失败时不要把不完整记录交给后续逻辑
        }
        saved = append(saved, record) // 这里只复制了切片头，没有复制记录容器
    }

    fmt.Println(saved[1])
    fmt.Println(saved[2])
}

这个例子中，saved 里每一项都只是一个切片描述符：它记录了指针、长度和容量。开启复用后，多个描述符可能指向同一份 []string backing array。后续 Read 写入新字段时，旧项看到的索引位置也会变化。

[id name]
[2 Linus]
[2 Linus]

输出里的第一行表头仍然可能正常，因为它和数据行的长度、读取时机不同；真正值得关注的是缓存中的两个数据记录共享了容器。这个现象不是 CSV 引号、逗号或换行解析失败。

ReuseRecord 复用的到底是什么

官方文档对 ReuseRecord 的描述是：连续调用 Read 时，返回的切片可能共享上一轮返回切片的 backing array；默认情况下，每次调用会返回新分配且由调用方拥有的内存。这里有两个层次要分开。

当前 Go 的 CSV 解析器会把一行字段组织成字符串，再从中切出字段字符串；源码里的 lastRecord 只在复用模式下作为记录切片缓存。因而这里的修复重点是复制切片容器，而不是对每个字段调用 strings.Clone。

正确修复：在所有权交接处复制

如果记录只在当前循环里立即转换或写入数据库，可以继续使用复用模式；如果要放进 saved、队列、缓存或异步任务，就在交接处复制。

func cloneRecord(record []string) []string {
    // 复制 []string 的 backing array，让保存项不再依赖 Reader 的下一次 Read。
    return append([]string(nil), record...)
}

func collect(input string) ([][]string, error) {
    reader := csv.NewReader(strings.NewReader(input))
    reader.ReuseRecord = true // 读取阶段复用，保存阶段显式复制

    var saved [][]string
    for {
        record, err := reader.Read()
        if err == io.EOF {
            return saved, nil // 读完后返回已经脱离 Reader 的记录
        }
        if err != nil {
            return nil, err // 把行号等解析错误交给调用方处理
        }
        saved = append(saved, cloneRecord(record)) // 所有权在这里交接
    }
}

append([]string(nil), record...) 会创建一个新的字符串切片，并把字段值复制进去。原来的 record 仍可由 Reader 复用，但 saved 中的行已经拥有独立的容器。

一个小项目里怎样选择策略

可以把 CSV 读取器拆成“读取阶段”和“保存阶段”。读取阶段只负责解析；保存阶段决定是否把所有权从 Reader 手里接过来。

• 只在本轮循环使用：保持 ReuseRecord=true，立即完成字段校验、转换或写入。
• 跨循环保存：保存前复制 []string，尤其是追加到二维切片或放进闭包时。
• 异步消费：把复制动作放在发送到 channel 或任务队列之前，不要让消费者依赖 Reader 的生命周期。
• 不想维护复制边界：关闭 ReuseRecord，让每次 Read 使用默认的新记录切片；代价是更多分配。

还要注意，Read 可能同时返回一条部分记录和解析错误，调用方不能因为拿到了非空切片就忽略错误。若使用 ReadAll，它会持续读取剩余记录；当你需要长期保留结果时，仍应明确检查是否启用了复用模式，并让代码的所有权约定保持一致。

常见问题

关闭 ReuseRecord 就一定更好吗？

不一定。短生命周期处理可以用复用来减少分配；只有当记录会离开当前读取循环时，复制才是必须的。关闭复用更简单，但会把内存分配成本交给每次读取。

需要把每个字段都 strings.Clone 一遍吗？

这个问题的核心通常不是字段字符串，而是记录切片的 backing array。只要代码不把字段转换为后续还会被修改的字节缓冲区，复制 []string 容器就足够表达保存边界。

总结

ReuseRecord 是读取性能和对象所有权之间的取舍：它可以让连续 Read 返回的记录切片共享底层数组。把记录直接追加到缓存时，复制的只是切片头，旧记录就可能随着下一行读取而变化。记住一条边界即可：当前循环立即消费就复用，跨循环、入队或异步保存就先 append([]string(nil), record...)。