Go CSV 开启 ReuseRecord 后记录都变了：先明确切片的使用期限

CSV文件里明明有a和b两条记录，收集到切片里却都变成了b。常见原因是开启了ReuseRecord，又把每次Read返回的切片直接保留到下一次读取之后。

这个选项允许Reader复用返回记录的切片存储。它没有承诺每次交出一份独立快照。当前记录就地处理完再读下一条，通常没有问题；要跨读取保留，调用方需要承担复制责任。

先用两行数据固定重现，不拿随机大文件比较性能。复用可以减少某些分配，但本文只验证所有权，不能从一次小实验推导吞吐收益。

看见同一份切片被下一条记录覆盖

使用Go 1.24.1，保存为main.go，在独立模块执行go run .。

package main

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

func collect(text string, copyRecord bool) ([][]string, error) {
    reader := csv.NewReader(strings.NewReader(text))
    reader.ReuseRecord = true
    reader.FieldsPerRecord = 2
    var rows [][]string
    for {
        record, err := reader.Read()
        if err == io.EOF { return rows, nil }
        if err != nil { return nil, err }
        if copyRecord { record = append([]string(nil), record...) }
        rows = append(rows, record)
    }
}

func main() {
    const text = "a,1\nb,2\n"
    reused, err := collect(text, false)
    if err != nil { panic(err) }
    copied, err := collect(text, true)
    if err != nil { panic(err) }
    fmt.Println("retained without copy:", reused)
    fmt.Println("retained with copy:", copied)
    if !reflect.DeepEqual(copied, [][]string{{"a", "1"}, {"b", "2"}}) {
        panic("record snapshot lost")
    }
    if !reflect.DeepEqual(reused, [][]string{{"b", "2"}, {"b", "2"}}) {
        panic("controlled reuse example changed")
    }
    _, err = collect("a,1\nb,2,extra\n", true)
    var parseError *csv.ParseError
    fmt.Println("field count rejected:", errors.As(err, &parseError) &&
        errors.Is(err, csv.ErrFieldCount))
    quoted, err := collect("\"line one\nline two\",3\n", true)
    if err != nil { panic(err) }
    fmt.Printf("quoted newline: %q\n", quoted[0][0])
}

未复制时，两份保留记录都显示b、2；复制后仍是a、1与b、2。字段数量不符被拒绝，最后一个样本则说明双引号内的换行属于字段内容，不等于新记录边界。

复用并不要求每份输入都恰好表现为“全部变成最后一行”。记录长度、容量增长和实现路径会影响哪些底层数组被重新使用。演示断言针对固定版本与两条等长记录，接口层真正的约束是不能依赖跨Read保留的记录切片仍然不变。

复制切片就够了，还是还要复制字符串

CSV记录是[]string。这里需要复制的是存放字段字符串的切片元素，避免后续读取改写同一组元素。普通Go字符串不可变，因此无需为了这项复用问题把每个字符串再深拷贝一份。

append到nil切片会创建当前记录的独立元素存储。也可以用明确的切片克隆工具，关键是新记录不再共享那份可复用数组。只写 snapshot := record 复制的是切片描述，仍然共享元素，并没有建立快照。

如果后续把字段转成自定义可变对象，所有权又要重新判断。此次切片复制只解决当前[]string的共享层次，不能顺手扩大成任意复杂对象都安全深复制的结论。

不需要保留明细时，可以在当前Read之后直接验证、累计或转换成独立业务值，然后再读下一条。这样更符合复用选项的使用场景。为了“安全”先复制每条，再立刻丢弃，有时只是同时支付了复用复杂度与复制成本。

扔进通道，不会自动转移底层数组

生产者Read以后把record发给消费者，看起来已经完成交接，但发送切片只传递描述，并不复制底层字段数组。生产者继续Read时，消费者可能还没处理完，内容就被下一条覆盖；并发读写还可能产生数据竞争。

最直接的办法是在发送前复制记录，再明确消费者拥有这份副本。也可以设计受控缓冲池与归还协议，但必须保证归还前不会复用，而且所有错误与退出路径都会完成归还。没有明确容量压力时，不必为一个选项引入复杂资源协议。

只有明确记录使用结束的时点，才有资格允许下一轮覆盖。

单线程也可能出同样错误。把record闭包捕获到稍后执行的任务里，或者收集到待批量写入列表，都会把生命周期延长到下一次Read之后。是否使用goroutine不是判断标准，关键是记录何时不再被使用。

字段错误时，当前返回值不等于可提交记录

CSV解析器在某些错误路径上仍可能给出部分记录，或者在字段数量不符时给出解析出的字段。调用方应按自己的导入合同决定处理方式，不能看record非空就忽略err。

本例遇到任何非EOF错误都返回nil和错误，表示整批收集失败；之前已读记录没有外部副作用，所以可以整体丢弃。若改成边读边写数据库，就无法靠return nil撤回已经提交的数据，需要另外定义事务、分批确认和失败续跑。

这与原始Reader“先处理n个字节再看err”处在不同抽象层。字节确实已经读到，不代表它们已经组成符合CSV字段规则的业务记录。应遵守每层解析器的完成合同，而不是把一个循环顺序机械复制到所有接口。

字段数也要显式选择。FieldsPerRecord设为2表示本文固定两列；默认值可以依据首条记录建立期望，负值则放开数量检查。导入格式已知时，不应为了让错误样本通过就关闭检查，随后又按固定下标读字段。

复用之外，仍需限制这批输入

collect把全部记录留在内存，只是为了让错误结果清楚可见。真实导入还要限定请求大小、记录数量与字段内容，尤其不能以为ReuseRecord就给整批收集设置了内存上限。每次复制并保存的行仍然会持续占用空间。

CSV允许带引号字段包含换行，不能先按行Split再把每行交给解析器，也不能拿物理行数直接当记录数。出错时可以利用ParseError的行列信息定位，但报告给使用者前仍应按界面需要处理，不要把全部敏感原文附进错误日志。

保留这份两行实验，再分别试“即时求和”“保存到列表”“发送到工作者”。每改一次消费生命周期，都明确谁拥有返回切片、下一次Read何时允许发生。真正需要审查的是这段时间关系，而不是ReuseRecord这个布尔值本身。