Go csv.Reader 开启 ReuseRecord 后怎样避免行数据被覆盖

我在处理大文件 CSV 时，曾经把每次 Read() 返回的记录直接放进结果切片。代码看起来省分配，结果却出现了一个很像“数据串行”的现象：前面保存的行，过一会儿变成了后面读到的内容。问题不在 CSV 文本，而在 ReuseRecord 改变了记录切片的持有方式。

官方地址：https://pkg.go.dev/encoding/csv#Reader

开启 ReuseRecord 后，Read 返回的 []string 可能与上一次返回值共享底层数组。当前循环马上消费可以直接用；只要要跨轮保存、异步传递或延迟处理，就在读取边界复制一份切片。

先复现上一行被改写的现象

先把问题缩小到“保存记录引用”这件事。下面的示例只展示 API 关系，不把输出当作运行截图：rows 保存的是每一轮返回的切片，而不是每一轮独立的字段容器。

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

    var rows [][]string
    for {
        record, err := reader.Read()
        if err == io.EOF {
            // 没有更多记录时正常结束读取。
            break
        }
        if err != nil {
            // 真实导入应记录解析错误，这里只停止示例。
            panic(err)
        }
        // 这里保存了可能被下一次 Read 复用的切片。
        rows = append(rows, record)
    }
    fmt.Println(rows)
}

关键点是最后一行：record 的类型虽然是 []string，但开启复用后，它不一定拥有独立的底层数组。下一次 Read 可以把新字段写回同一块数组，于是 rows 中旧位置看到的内容也可能随之变化。

看清 ReuseRecord 的复用边界

官方文档把 ReuseRecord 描述为性能选项：开启后，连续调用 Read 时，返回切片可能共享上一次返回切片的底层数组；默认值为 false，每次读取返回由调用方持有的新分配内存。

这句话可以拆成两层理解。第一层是“切片容器可能复用”：record 的长度、容量和元素槽位属于切片结构。第二层是“元素是字符串”：把切片复制出来，通常就能让历史行拥有独立的 []string 容器；这不是把 CSV 再解析一遍，也不是复制整个输入文件。

因此，下面两种代码的生命周期不同：

// 立即消费：处理结束前不会进入下一次 Read，可以直接使用 record。
func handleCurrent(record []string) error {
    if err := consume(record); err != nil {
        // 当前记录处理失败时，把错误交给调用方。
        return err
    }
    return nil
}

// 跨轮保存：复制切片后再交给结果集合或异步任务。
func keepForLater(record []string, pending *[][]string) {
    // 复制后，后续 Read 复用原切片也不会改写这份记录。
    saved := append([]string(nil), record...)
    *pending = append(*pending, saved)
}

这里的判断标准不是“这一行现在能不能打印”，而是“下一次 Read 之后还要不要继续使用它”。如果答案是要，引用就必须脱离可复用数组。

在读取边界复制需要保留的行

实际导入通常只需要复制那些会离开当前循环的行。下面的写法保留了 ReuseRecord 的意图，同时把需要延迟处理的记录放入独立切片：

func collect(reader *csv.Reader) ([][]string, error) {
    var result [][]string
    for {
        record, err := reader.Read()
        if err == io.EOF {
            // 没有更多记录时正常结束读取。
            return result, nil
        }
        if err != nil {
            // 解析错误不应被当成成功数据继续传递。
            return nil, err
        }

        // 只有要跨过下一次 Read 保存时，才复制字段切片。
        independent := append([]string(nil), record...)
        result = append(result, independent)
    }
}

这个函数的复制对象是 []string，不是 string 的字符内容。字符串值本身按 Go 的值语义放进新切片；我们要隔离的是记录切片的元素槽位。若后续业务还会修改某个字符串内容，应在业务边界另行处理，因为那已经不是 ReuseRecord 的问题。

按消费方式选择是否复制

一个容易忽略的取舍是：关闭 ReuseRecord 最省心，却放弃了这项减少切片分配的设置；全部复制最直观，却会把节省下来的分配重新部分加回来。对大文件导入，更实用的办法往往是让当前行在循环里完成轻量处理，只对确实要排队、重试或批量提交的记录复制。

速查：怎样避免行数据被覆盖

• 使用 ReuseRecord 时，不要把 record 原样保存到跨轮容器。
• 只要下一次 Read 后还要用，就执行 append([]string(nil), record...)。
• 传给 goroutine、缓存队列、重试列表前，按异步生命周期复制。
• 若不需要控制分配，保持默认 ReuseRecord=false 可以减少所有权判断。

复制 record 会不会复制整份 CSV 文件？

不会。示例只复制当前记录的字符串切片容器，不会复制 reader 尚未读取的输入，也不会重新解析字段。

为什么打印时看不出问题，保存后才出问题？

因为打印通常发生在当前读取轮次内，而保存后的消费发生在后续 Read 之后；复用风险正好出现在这段生命周期差异中。

记住一个判断：ReuseRecord 优化的是读取时的切片复用，不会替你管理跨轮数据所有权。记录要离开当前读取边界，就先复制，再交给后续流程。