A Go import sets csv.Reader.ReuseRecord = true and keeps every record; why do all rows end up identical?

## What the flag buys `csv.Reader` has a `ReuseRecord bool` field. When it is true, calls to `Read` may return a slice that shares the backing array of the previous call's returned slice. The point is allocation: a long import calls `Read` millions of times, and each call otherwise allocates a fresh `[]string`. Turning that off is a measurable win in a hot import loop, and it is exactly the kind of knob you reach for after a benchmark with `-benchmem` has shown you where the allocations are. The contract it asks for in exchange is simple and unforgiving: **the record you get is only yours until the next `Read`.** ## How the bug forms ```go r.ReuseRecord = true var rows [][]string for { rec, err := r.Read() if err == io.EOF { break } rows = append(rows, rec) // the bug } ``` `append` copies the slice *header* — pointer, length, capacity — not the elements it points at. Every element of `rows` therefore holds a pointer to the same array. The next `Read` overwrites that array in place. When the loop ends, all N entries of `rows` are N views of one array holding the final record, and the import writes the last row a hundred thousand times. Re-slicing does not help: `rec[:]` produces another header pointing at the same array. Assigning to a new variable, storing it in a struct field, passing it to a goroutine — all the same. Nothing short of copying the elements breaks the aliasing. ## The fix ```go rows = append(rows, slices.Clone(rec)) ``` `slices.Clone` allocates a new backing array and copies the elements, so the retained row is independent. `append([]string(nil), rec...)` is the older spelling of the same thing. If all you need from the record is a couple of fields, take them out by value and let the record go — a `string` you have copied into a struct field is yours regardless of what happens to the record slice. So the rule is: **clone whenever the record outlives the loop iteration.** ## Why nothing warns you This is the part that makes it a senior question. It is not a data race — a single goroutine reads and appends, and the reuse is ordinary sequential mutation — so the race detector reports a clean run no matter how long you exercise it. `go vet` has no check for retaining a reused record. The compiler is happy: the types are all correct. The only signal is the data itself, and only if someone looks at more than one row. It also hides in testing. A fixture with a single record cannot show the problem: with one row there is nothing to overwrite it. A fixture with two rows shows it immediately, which is why the cheap reproduction is a unit test over a two-record input asserting `rows[0][0] != rows[1][0]`. That test is worth writing even after you fix it, because the fix is one call that a future refactor can quietly delete. ## Where it typically surfaces A batch import over partner files runs for months. Somebody profiles it, sees the per-record allocation, sets `ReuseRecord = true`, benchmarks it, ships it. The import loop at that time consumed each record inline, so nothing broke. Six months later a feature needs the rows collected — for a summary, a dedupe pass, a bulk write — and the collecting code is written by someone who never saw the flag three files away. Every imported row is now the last row of the file, and the symptom looks like a corrupt export from the partner rather than a bug in the reader configuration. That is worth remembering when you are the one reviewing the PR: a flag whose safety depends on what the *caller* does with the value is a flag that needs a comment at the point it is set, not only at the point it is used. ## And ReadAll `ReadAll` allocates a fresh record for each row, so the `[][]string` it returns holds independent slices and `ReuseRecord` does not affect it. The flag exists purely for the streaming path. ## The judgement Default to leaving `ReuseRecord` false. Turn it on only when a benchmark says the allocation matters, only when the loop body demonstrably consumes the record before the next iteration, and with a comment saying so. One saved allocation per row is not worth an import that silently writes the same record a million times.