In Go, why can keeping strings.TrimSpace's result hold a whole 10 MB document in memory?

## What a Go string actually is A `string` value is a two-word header: a pointer to bytes and a length. The bytes are immutable, which is precisely what lets the runtime share them freely. `s[a:b]` therefore allocates nothing — it produces a new header pointing `a` bytes into the same array with length `b-a`. `strings.TrimSpace(s)` is defined entirely in terms of moving those two ends inward past white space, so its result is a substring of `s` sharing the same storage. So are `strings.TrimPrefix`, `strings.TrimSuffix`, `strings.Trim` and the rest of the trim family. None of them copy. ## Why that becomes a memory problem Go's garbage collector reclaims **whole allocations**. A byte array is either reachable or it is not; there is no way to free the unreferenced middle of one. So a single 80-byte header pointing into a 10 MB array keeps all 10 MB alive for as long as that header is reachable. The shape that produces it is ordinary and looks harmless: a normaliser reads a document, trims a few fields out of it, writes those fields into a long-lived structure — a cache, an index, a batch being accumulated — and drops the document. Every retained field is an anchor. Memory grows in proportion to the number of *documents processed*, not the size of what you kept, and it looks exactly like a leak: the live heap climbs, a heap profile shows a large share of `inuse_space` in the byte slices produced by whatever read the input, and nothing in the retaining code allocates enough to explain it. The tell in a heap profile is that the memory is attributed to the reading path, not to the code that holds the data — that mismatch between where it was allocated and what is keeping it alive is the signature of retention rather than over-allocation. ## The fix `strings.Clone(s) string` returns a copy of `s` with fresh backing storage, so the copy shares nothing with the original. Apply it at the boundary where a short value outlives the large one it came from: ```go title := strings.TrimSpace(doc[start:end]) index[id] = strings.Clone(title) ``` Any operation that genuinely builds a new string has the same effect as a side-benefit — `strings.ToLower` on text that actually contains uppercase, or a `Replacer` that matched something, both produce independent storage. That is worth knowing precisely because it makes the bug *intermittent*: a pipeline that lowercases every key never sees this, until someone adds a fast path that skips the transformation when the input is already lowercase. ## The flip side — do not clone everywhere The sharing is a feature, and it is why this package is cheap in the common case: - `strings.TrimSpace` never allocates; it returns a substring. - `strings.ToLower` returns **the input string itself** when no character needs changing, which is the common case for already-normalised text. - `strings.Replace` returns the input unchanged when there is no match, so a replacement pass over text that does not contain the pattern is a scan with no copy. Cloning by reflex throws all of that away and adds an allocation per field to a hot path. The discipline is narrow: clone when a **small** value derived from a **large, otherwise-dead** buffer is going to be **retained**. Values that are compared, written out and discarded within the call need nothing. ## Confirming it rather than guessing Two cheap checks settle it. A benchmark run with `-benchmem` reports bytes and allocations per operation, which tells you whether a normalisation step is copying at all — a step reporting 0 allocs/op is sharing, and sharing is what creates retention. And a heap profile taken while live heap is climbing shows whether the surviving bytes belong to the read buffers rather than to the structure that appears to hold the data. The same golden-file corpus you use to check the normaliser's output is a good input for both, because it is the text the service actually sees rather than a synthetic string.