Escape analysis moves a hot-path helper's locals to the heap. How do you remove that allocation without changing behaviour?

## Establish the fact before the theory A helper that allocates on every call is worth attention only if it is genuinely hot and the allocations are genuinely yours. Confirm both first: a benchmark showing allocs/op greater than zero for the operation, and the compiler's own account of what escapes. `go build -gcflags='-m -m'` on the package prints each decision plus the reasoning chain that produced it. Build the single package, not the whole tree — the full output is unusable. What you are looking for is not the `moved to heap` line, which is the symptom. It is the end of the chain: the return, the assignment, or the call that forced the value's lifetime past the frame. ## The four causes, and what each one costs to fix **1. The helper returns a pointer to a local.** The lifetime demand is in the signature. If the value is small and callers do not need to observe mutations through a shared pointer, returning it by value moves the storage into the caller's frame and the escape disappears. If callers do share it, this is a real requirement and the allocation is correct — leave it. **2. The helper hands a pointer to a callee reported as `leaking param`.** The callee stores the pointer somewhere longer-lived, so the compiler must assume your local escapes. The fix lives in the callee: if it only needs the data during the call, stop retaining it, and the caller's local goes back on the stack. This is the case that most often looks mysterious, because the allocation is attributed to your function while the cause is in someone else's. **3. The value passes through a call the compiler cannot see into.** An indirect call — through an interface value or a function-typed field — gives escape analysis no callee to inspect at that site, so it conservatively assumes the pointer leaks. Making the call direct, or accepting a concrete type where the abstraction is not earning anything, restores the analysis. This is a design change, not a micro-optimisation, and should be argued as one. **4. The allocation has no compile-time-constant size, or is too large.** `make([]byte, n)` with a variable `n` cannot be placed in a frame whose size must be known when the function is compiled, so it goes to the heap; the same applies to a local far larger than the compiler is willing to keep in a frame. Fixing this means bounding the size as a constant, or moving the allocation out of the hot path entirely. ## The shape that usually wins: let the caller own the memory The most durable fix in Go is a signature change rather than a body change. Instead of a function that allocates a result and returns a pointer to it, write one that takes a destination and writes into it: ```go func Scale(p *Point, f int) *Point // allocates per call func ScaleInto(dst, p *Point, f int) // caller owns dst ``` The callee now retains nothing, so its parameters are reported as not escaping, and the caller's `dst` can live in the caller's own frame across many calls. The same pattern applies to byte slices: take a `dst []byte`, append to it, return the extended slice. This is a genuine API change and it is not free. It pushes lifetime management onto callers, it is easier to misuse, and it reads worse. That is the trade you are making, and it should be made only where a measurement justifies it — typically an exported helper on an inner loop, not a general style. ## Verifying, and the discipline that keeps it honest Three checks, in this order: 1. The tests still pass. Behaviour is the constraint; if it changed, the optimisation is not the same function. 2. The escape line changed. Rerun `-gcflags='-m -m'` and see `does not escape` where you saw `moved to heap`. 3. The benchmark moved. Run it with -benchmem and compare allocs/op and ns/op before and after. The compiler's diagnostic is evidence about the compiler; the benchmark is evidence about the program. The third check is the one people skip, and it is the one that catches the case where the allocation was never on the path that mattered. ## What not to do Do not treat escape output as a contract to be enforced. The analysis improves between compiler releases, and a decision you worked around this year may be made for you next year; pinning the current output into CI freezes behaviour that is legitimately allowed to change. Do not restructure code for an escape you have not measured, and do not remove an escape the semantics require by handing out memory whose lifetime you can no longer reason about — a correctness bug is a much worse outcome than an allocation.