i总是最终值是因为Go for循环复用同一内存地址，闭包捕获的是变量引用而非值；所有迭代共享该地址，循环结束后i定格为终值，同步或异步执行均输出相同结果。
闭包捕获循环变量时，i 为什么总是最终值
因为 Go 的 for 循环复用同一个变量内存地址，所有闭包共享该变量的引用，而非每次迭代创建新变量。即使循环结束前 i 已被赋值为 3，后续执行的闭包（如 goroutine 或延迟调用）读到的仍是这个终值。
这不是并发问题，纯同步代码也会复现：
for i := 0; i < 3; i++ {
f := func() { fmt.Print(i, " ") }
f() // 输出：3 3 3，不是 0 1 2
}
- 根本原因：迭代变量
i是单个绑定，每次只是改写其值 - 闭包捕获的是
i的地址，不是当前值的副本 - Go 1.22+ 对
range中的值变量做了复制优化，但显式for变量行为未变，不可依赖
如何让每次迭代的闭包拿到正确的 i 值
只有两种可靠方式，本质都是切断对原循环变量的引用：
-
传参捕获（推荐）：把当前值作为参数传入匿名函数，求值发生在调用时刻
go func(val int) { fmt.Println(val) }(i) -
循环内重声明：在循环体中用
i := i创建新局部变量for i := 0; i
注意：i := i 不是冗余赋值，而是变量遮蔽（shadowing），它为每次迭代分配独立栈空间；而 var i = i 语法错误，go func(i int) 必须立即调用 (i)，否则仍捕获外层 i。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
闭包延长变量生命周期的真实代价
只要闭包还存活，它捕获的变量就无法被 GC 回收——哪怕外层函数早已返回。这容易引发内存泄漏，尤其在高频场景下：
- HTTP handler 中闭包捕获整个
*http.Request，可能让请求体长期驻留堆上 - 循环中把闭包存入切片或 map 后未清理，所有被捕获的变量持续滞留
-
defer闭包捕获大结构体，触发逃逸分析，强制抬升到堆
验证方法：用 go build -gcflags="-m -l" 查看是否出现 ... moved to heap；若小变量也被抬升，大概率是闭包捕获了它所属的大对象（比如只用了 user.ID，却捕获了整个 user）。
defer 里的闭包也遵循同样规则
defer 闭包读取的是执行时变量的当前值，不是注册时的快照。常见陷阱：
for i := 0; i < 3; i++ {
defer func() { fmt.Print(i, " ") }() // 输出：3 3 3
}
修复方式与普通闭包一致：
- 立即传参：
defer func(val int) { fmt.Print(val, " ") }(i) - 循环内重声明：
i := i; defer func() { fmt.Print(i, " ") }()
命名返回值更要小心：defer func() { err = fmt.Errorf(...) }() 会直接修改返回值，且延长 err 生命周期——这种隐式副作用容易被忽略。
