go闭包捕获的是变量内存地址而非值快照，导致for循环中所有闭包共享同一变量地址而输出终值；修复方式是在每次迭代中创建新变量（如v := v）或通过参数传值（如func(val string) {…}(v)）。
闭包捕获的是地址，不是值
Go 的闭包不“拍快照”，它直接绑定到外部变量的内存地址。这意味着只要那个变量后续被修改，所有引用它的闭包在执行时都会看到最新值——哪怕你写的是 func() { fmt.Println(v) }，它读的也不是定义那一刻的 v，而是执行那一刻的 &v 所指向的内容。
典型现象：for _, v := range items { go func() { process(v) }() } 启动的所有 goroutine，最终都处理最后一个 v；cron.AddFunc("@every 1m", func() { log.Println(job.Name) }) 注册的全部任务，日志里只显示最后一个 job.Name。
根本原因不是“延迟执行”，而是 v 和 job 在整个循环中复用同一块栈内存——闭包拿到的是 &v 或 &job，不是副本。
循环中创建新变量是唯一可靠解法
必须切断变量复用链。只有在每次迭代中显式声明一个新变量并赋值，才能让闭包捕获独立地址：
-
val := v; go func() { process(val) }()—— 推荐，语义清晰，编译器对短变量声明有逃逸优化，性能无负担 -
go func(val string) { process(val) }(v)—— 传参式，v在go语句执行时立即求值并复制，闭包内val是独立参数 - 不要用
func(v string) { ... }(v)注册回调（如cron.AddFunc），因为这是 IIFE，返回的是调用结果，而接口要求的是func()类型
验证是否生效？加一行日志：log.Printf("v addr: %p, val addr: %p", &v, &val)，你会看到 &v 恒定不变，&val 每次都不同。
闭包持有大对象会阻碍 GC
闭包隐式持有所引用的所有外部变量。如果闭包被长期持有（比如注册为 HTTP handler、存入全局 map、或启动后台 goroutine），而它又无意中捕获了大对象（如 *http.Request、context.Context、几 MB 的 []byte），那这块内存就无法被垃圾回收器释放，哪怕业务逻辑早已不需要它。
常见高风险场景：
- 事件回调注册闭包 → 风险高，需配套提供注销机制
- goroutine 中捕获
req或ctx→ 中高风险，应改用参数传递关键字段，而非整个对象 - 临时计算用闭包 → 风险低，无需特殊处理
结构体虽是值类型，但若含指针字段（如 data *[]byte），复制结构体仍可能共享底层数据；切片、map 更要小心——变量本身复制了，底层数组/哈希表没变。
defer 中的闭包陷阱更隐蔽
defer 不改变闭包捕获规则，但它放大了变量生命周期问题：所有 defer 共享函数作用域，且统一在函数返回前执行。此时变量可能已被覆盖、未初始化，甚至被遮蔽。
典型错误：
-
var err error; defer log.Printf("err: %v", err)放在函数开头，但err实际在后面才赋值 → 日志总输出<nil></nil> for i := 0; i → 全部打印终值，比如 <code>3-
defer func() { x = 2 }()配合命名返回值 → 修改了返回值，但逻辑难追踪
安全做法：提前声明需要记录的变量（如 var err error），或把 defer 移到具体错误分支内部；循环中用 idx := i; defer fmt.Println(idx) 隔离。
真正容易被忽略的是：闭包捕获变量地址这件事，在 go、defer、http.HandleFunc、time.AfterFunc 等所有延迟执行场景下，行为完全一致——没有例外，也没有“按值捕获”语法糖。靠直觉判断哪次是“安全”的，大概率踩坑。
