Range Variable & Goroutine Closure Bugs

You launch ten goroutines in a loop and every one prints 10 instead of 0 through 9.

This page explains loop variable capture, what Go 1.22 changed, and the defensive patterns that still matter for defer, nested closures, and libraries targeting older Go versions.

Summary

A closure captures variables by reference, not by loop-iteration snapshot.

Before Go 1.22, the for loop's single i or range value variable was reused each iteration, so goroutines started in the loop often observed the final value.

Go 1.22+ creates a new variable per iteration for for and range, fixing the common case, but defer inside loops, manual outer-variable closures, and code compiled with older go directives still require explicit copies.

Recipe

Quick-reference recipe card - copy-paste ready.

// Defensive (all versions): copy before goroutine
for _, item := range items {
    item := item
    go func() {
        process(item)
    }()
}
 
// Go 1.22+ per-iteration vars (default with go 1.22 in go.mod)
for i := range n {
    go func() {
        process(i) // each goroutine gets its own i
    }()
}
 
// Pass as parameter (clearest)
for _, item := range items {
    go func(it Item) {
        process(it)
    }(item)
}

When to reach for this:

• Spawning goroutines inside any loop
• errgroup or worker pools over a collection
• Table tests with t.Parallel() inside range
• Scheduling callbacks that close over loop vars
• Maintaining libraries that must compile on Go 1.21 or older

Working Example

package main
 
import (
    "fmt"
    "sync"
)
 
func buggy(ids []int) {
    var wg sync.WaitGroup
    for _, id := range ids {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Println("buggy", id) // may print last id only on pre-1.22 semantics
        }()
    }
    wg.Wait()
}
 
func fixed(ids []int) {
    var wg sync.WaitGroup
    for _, id := range ids {
        wg.Add(1)
        id := id
        go func() {
            defer wg.Done()
            fmt.Println("fixed", id)
        }()
    }
    wg.Wait()
}
 
func main() {
    ids := []int{1, 2, 3}
    buggy(ids)
    fixed(ids)
}

What this demonstrates:

• Closure captures id by reference to the loop variable address
• id := id creates a per-iteration binding safe for the goroutine
• Parameter passing go func(id int) { ... }(id) documents intent in code review
• Always Wait() or use errgroup so main does not exit before goroutines run

Deep Dive

How It Works

• Loop variables live for the whole loop statement, not per iteration (pre-1.22)
• Goroutine scheduling means the loop may finish before children run, leaving only the final value
• Go 1.22 release notes: per-iteration loop variables for for and range under go 1.22 language version
• defer in a loop still stacks defers until the function returns, not per iteration

Version and Tooling

Go Notes

// defer in loop: BAD - all defers run at function exit
for _, f := range files {
    defer f.Close()
}
 
// GOOD - scoped function per iteration
for _, f := range files {
    func() {
        defer f.Close()
        // work with f
    }()
}

Gotchas

• Assuming Go 1.22 fixed every closure bug - Outer variables from enclosing scopes still alias. Fix: copy anything mutable the closure reads.
• defer in loops - Defers accumulate; files stay open until function end. Fix: nested function per iteration.
• Table tests with parallel subtests - t.Run(tc.name, func(t *testing.T) { t.Parallel(); use(tc) }) needs tc := tc. Fix: copy before t.Run.
• Worker pools reading loop index - Pool goroutines may run after loop completes. Fix: pass index as task field.
• Libraries without go.mod version bump - Consumers on 1.22 still see old behavior if library sets older language. Fix: defensive copy in library code.
• Closures in HTTP handlers registering callbacks - Registration closes over loop var from setup. Fix: pass parameters at registration time.

Alternatives

FAQs

Related

• Debugging Go: Observable Failures and Sharp Edges - closure symptom family
• Goroutine Leaks & Missing Context Cancellation - defer-in-loop leaks
• Data Race Scenarios & race Detector Fixes - races with shared loop state
• for Loop Variants & range Semantics - range forms
• Control Flow Best Practices - loop and goroutine rules

Stack versions: This page was written for Go 1.26.x (Green Tea GC default, go fix modernizers - verify patch at build), chi (latest - verify at build), gin (latest - verify at build), echo (latest - verify at build), google.golang.org/grpc (latest - verify at build), sigs.k8s.io/controller-runtime (latest - verify at build), kubebuilder (latest - verify at build), tinygo (latest - verify board targets at build), wazero (latest - verify at build), and golangci-lint (latest - verify linter set at build).