答案。

在 Go 中，for 循环结构可以包含初始化块（init）、条件检查和后缀表达式。历史上，这种机制是为了方便编写代码和适应 C 类语言的习惯。然而，在 Go 中，循环变量（i）的作用域具有独特性，这会严重影响嵌套函数、闭包和 goroutine 内部的行为。

问题 — 在循环的每次迭代中启动 goroutine 或闭包，往往会出现意外行为：变量 i 不会被复制，而是“通过引用捕获”，也就是说闭包访问的是循环的共享变量，该变量在循环结束后会取最后的值。这会导致所有 goroutine/闭包的结果相同，尽管逻辑可能设想了不同的结果。

解决方案 — 当需要传递每次迭代变量的值时，可以使用显式复制变量（通过额外变量）或将其作为参数传递给闭包。

代码示例：

for i := 0; i < 3; i++ {
    go func(j int) {
        fmt.Println(j)
    }(i) // 正确！复制的值
}

for i := 0; i < 3; i++ {
    go func() {
        fmt.Println(i)
    }() // 错误：所有 goroutine 都会打印 3
}

关键特性：

在 for 循环中，循环变量隐式在 for 块的作用域中声明。
在闭包/goroutine 中捕获循环变量会导致变量在所有闭包实例之间“共享”。
通过在每次迭代中复制变量到新变量来避免这个问题。

诱导性问题。

使用 break 或 continue 时，for 循环变量的作用域会改变吗？

不会。在 for 循环中声明的变量的作用域始终限于该循环的块。 break 或 continue 仅中断当前的迭代，而不将变量“转移”到外部。

可以在循环外的方法中捕获在 for的 init 部分声明的变量吗？

不可以。变量仅在 for 及其所有嵌套块内可见，但在循环结束后不在其外部可见。

如果在 for 中的 defer 表达式捕获变量，会发生什么？

同样的情况：defer 函数“看到”的不是创建时的值，而是执行 defer 时的当前变量值（通常是循环的最后值）。

for i := 0; i < 3; i++ {
    defer fmt.Println(i) // 所有 defer 将打印 3
}

常见错误和反模式

未复制到新变量而捕获循环变量
在匿名函数中传递循环变量而未显式传递（后期绑定效应）
在循环中使用 defer 而未考虑变量的作用域

生活中的例子

负面案例

在 Go 的 web 服务器中，开发者启动了多个 goroutine 来处理不同的端口，使用端口索引作为循环变量，并直接在 lambda 表达式中捕获它。所有的 goroutine 都访问同一个端口——数组中的最后一个。

优点：

简单的“显式”循环实现

缺点：

逻辑不正确
难以理解的 bug

正面案例

团队制定了一条规则——始终将循环变量的值复制到新的变量中，再由闭包/goroutine 捕获。