Go 1.21 包含了一个对循环作用域的变更的预览，我们计划在 Go 1.22 中发布此变更，以消除其中一个最常见的 Go 错误。

问题

如果你写过任何数量的 Go 代码，你可能犯过保留循环变量的引用超过其迭代结束的错误，此时它会获得一个你不想要的新值。例如，考虑以下程序：

func main() {
    done := make(chan bool)

    values := []string{"a", "b", "c"}
    for _, v := range values {
        go func() {
            fmt.Println(v)
            done <- true
        }()
    }

    // wait for all goroutines to complete before exiting
    for _ = range values {
        <-done
    }
}

这三个创建的 goroutine 都在打印同一个变量 v，所以它们通常会打印出 "c"、"c"、"c"，而不是以某种顺序打印出 "a"、"b" 和 "c"。

Go 的常见问题解答中的条目 "闭包在作为 goroutine 运行时会发生什么？" 给出了这个例子，并指出 "使用闭包与并发时可能会导致一些混淆"。

尽管通常涉及并发，但并非必须如此。这个例子有相同的问题，但没有 goroutine：

func main() {
    var prints []func()
    for i := 1; i <= 3; i++ {
        prints = append(prints, func() { fmt.Println(i) })
    }
    for _, print := range prints {
        print()
    }
}

这种错误已经在许多公司引起了生产问题，包括1619047 - Let's Encrypt: CAA Rechecking bug的问题。在那种情况下，循环变量的意外捕获跨越多个函数，并且更难以注意到：

// authz2ModelMapToPB converts a mapping of domain name to authz2Models into a
// protobuf authorizations map
func authz2ModelMapToPB(m map[string]authz2Model) (*sapb.Authorizations, error) {
    resp := &sapb.Authorizations{}
    for k, v := range m {
        // Make a copy of k because it will be reassigned with each loop.
        kCopy := k
        authzPB, err := modelToAuthzPB(&v)
        if err != nil {
            return nil, err
        }
        resp.Authz = append(resp.Authz, &sapb.Authorizations_MapElement{
            Domain: &kCopy,
            Authz: authzPB,
        })
    }
    return resp, nil
}

这段代码的作者显然清楚地理解了这个通用问题，因为他们对 k 进行了复制，但是 modelToAuthzPB 在构造其结果时使用了 v 中字段的指针，所以循环也需要对 v 进行复制。

已经有工具被开发出来识别这些错误，但分析变量的引用是否超出其迭代的生命周期是很困难的。这些工具必须在误报和漏报之间做出选择。go vet和gopls使用的循环闭包分析器选择了误报，只有在确定存在问题时才报告，而漏报其他情况。其他检查器选择了误报，将正确的代码指责为错误。我们对添加了"x := x"行的开源Go代码进行了分析，期望找到bug修复。然而，我们发现许多不必要的行被添加进去，这表明流行的检查器存在相当高的误报率，但开发人员仍然添加这些行以保持检查器的满意。

我们找到的一对例子特别有启发性：

这个diff是在一个程序中的：

for _, informer := range c.informerMap {
+        informer := informer
         go informer.Run(stopCh)
     }

而这个diff是在另一个程序中的：

  for _, a := range alarms {
+        a := a
         go a.Monitor(b)
     }

其中一个diff是一个bug修复，另一个是一个不必要的更改。除非你了解涉及的类型和函数的更多信息，否则无法确定哪个是哪个。

修复方法

对于Go 1.22，我们计划修改for循环，使这些变量具有每次迭代的作用域，而不是每个循环的作用域。这个改变将修复上述例子，使它们不再是有bug的Go程序；它将终止由此类错误引起的生产问题；并且它将消除需要用户对其代码进行不必要更改的不准确的工具。

为了确保与现有代码的向后兼容性，新的语义将仅适用于在其go.mod文件中声明了go 1.22或更高版本的模块中的包。这个按模块划分的决定使开发人员可以控制在代码库中逐步更新到新语义。还可以使用//go:build行来控制每个文件的决策。

旧代码将继续保持与今天完全一样的含义：修复仅适用于新代码或更新的代码。这将使开发人员能够控制特定包中的语义更改的时间。作为我们前向兼容性工作的结果，Go 1.21将不会尝试编译声明了go 1.22或更高版本的代码。我们在Go 1.20.8和Go 1.19.13的修订版本中包含了具有相同效果的特殊情况，因此，在发布Go 1.22后，依赖新语义编写的代码将永远不会使用旧语义进行编译，除非使用非常旧的不受支持的Go版本。

预览修复方法

Go 1.21 包含了对作用域变更的预览。如果在环境中设置了GOEXPERIMENT=loopvar并使用该选项编译代码，那么新的语义将应用于所有循环（忽略 go.mod 中的 go 行）。例如，要检查在应用新的循环语义到您的包和所有依赖项后，您的测试是否仍然通过：

GOEXPERIMENT=loopvar go test

我们在谷歌的内部 Go 工具链中修复了此模式，并在 2023 年 5 月初开始的所有构建中强制使用该模式，在过去的四个月中，我们在生产代码中没有收到任何问题的报告。

您还可以尝试在 Go Playground 上包含一个 // GOEXPERIMENT=loopvar 的注释，以更好地理解语义，例如在这个程序中（Go Playground - The Go Programming Language）。请注意，这个注释仅适用于 Go Playground