In Go's encoding/csv, when would you use Reader.Read in a loop instead of Reader.ReadAll?

## The two ways to pull records out `encoding/csv` gives you a `*csv.Reader` built with `csv.NewReader(r io.Reader)`. A *record* is one row, represented as a `[]string` of already-unquoted fields: a quoted field containing commas or newlines arrives as a single element, so you never re-split anything yourself. There are exactly two ways to get records out: - `func (r *Reader) Read() (record []string, err error)` — one record per call. - `func (r *Reader) ReadAll() (records [][]string, err error)` — everything, at once. ## What ReadAll actually does `ReadAll` loops internally until the input is exhausted and then returns the accumulated slice. Two details matter and both surprise people: 1. **A clean run returns `err == nil`, not `io.EOF`.** `ReadAll` converts end-of-input into success. Code that checks `if err == io.EOF` around `ReadAll` never fires. 2. **An error returns nothing.** If record 4,271 is malformed, `ReadAll` returns a nil `[][]string` together with the error. The 4,270 records it had already parsed are discarded. You cannot recover partial work from it. That second point is why `ReadAll` is a poor fit for files you did not produce. A batch import over partner-supplied exports meets ragged rows, stray quotes and trailing summary lines routinely, and an all-or-nothing call turns each of those into "the whole file failed" with no way to report which row was at fault. ## What Read does `Read` returns one record and advances. End of input is signalled by `io.EOF`, which is the normal, expected termination of the loop, not a failure to log: ```go for { rec, err := r.Read() if err == io.EOF { break } if err != nil { return err } // use rec } ``` Always check the error before touching the record. A parse failure concerns one record and you may decide to log it and keep reading; an error coming from the underlying `io.Reader` ends the stream and there is nothing further to read. ## Memory, concretely A CSV on disk is bytes. A `[][]string` of the same data is Go strings plus a slice header per row plus a string header per field. A 2 GB file with many small fields expands well past 2 GB of live heap, and every one of those objects stays reachable for as long as you hold the outer slice, so the garbage collector cannot help you. Streaming with `Read` keeps only the current record plus whatever you have deliberately accumulated — a batch of a few thousand rows waiting to be written onward, say — and that batch size is a number you control. ## Choosing Use `ReadAll` when the file is small, trusted, and you genuinely need random access to all rows: a checked-in fixture, a lookup table of a few hundred lines, a test. Use `Read` when the file is large, when it comes from outside your system, when you want to stream each row onward as it is parsed, or when you need to keep going past a bad record instead of aborting. A useful middle ground for imports is `Read` in a loop with your own bounded batch: accumulate N records, hand the batch to the next stage, reset the batch. That gives you the throughput of bulk work without the unbounded footprint of `ReadAll`, and it keeps every parse failure attributable to a line number you can put in a rejects report. ## The habit to build Write the `Read` loop by default and reach for `ReadAll` only when you can say out loud why the whole file fits in memory. The loop is four extra lines, and it is the version that still works when the file grows or when a partner ships you a broken row.