golang-concurrency

Every goroutine needs a clear exit path: pass a context.Context and include a ctx.Done() case in every select loop, or use a done channel. Verify with go.uber.org/goleak in TestMain and run tests with go test -race to catch leaks and data races.

Use errgroup when goroutines return errors, need cancellation of siblings on first failure, or need bounded concurrency via SetLimit. Use WaitGroup only for simple fire-and-wait work with no error propagation; Go 1.25+ offers wg.Go for that case.

Use sync.Map only for write-once/read-many patterns or disjoint key sets per goroutine. For frequent writes with overlapping keys, RWMutex plus a plain map is faster. Unsynchronized concurrent map access causes a hard crash, not just a race.

Only the sender closes a channel; closing from the receiver panics if the sender writes afterward. If the receiver needs to stop the producer, use a separate done channel or context cancellation that the producer selects on.

Each time.After call allocates a new timer, causing churn in hot loops. Create one time.NewTimer outside the loop and call Reset after each event; on Go versions before 1.23, drain the channel if Stop reports a pending value.

Use iter.Seq iterators for sequential, CPU-bound, in-memory transformations where goroutines add overhead without benefit. Reserve goroutine-plus-channel pipelines for stages involving I/O or when you need true parallelism across cores.