go闭包捕获变量地址而非值，for循环中goroutine共享同一变量地址导致终值问题；错误写法因复用i地址，所有goroutine执行时i已为终值。
Go 闭包捕获外部变量时，不是拍快照，而是绑地址；高并发下多个 goroutine 共享同一变量地址，必然导致数据竞争、输出错乱或内存泄漏——这不是偶发 bug，而是语言机制决定的必然行为。
for 循环中直接启动 goroutine 为什么总输出终值
因为 i 或 v 是复用变量：每次迭代只改值，不换地址。所有 go func() { ... }() 捕获的都是同一个 &i，等 goroutine 真正执行时，循环早已结束，i 停在终值（如 len(items)）。
- 错误写法：
for i := 0; i → 几乎全输出 <code>5 - range 同理：
for _, v := range items { go func() { use(v) }() }→ 所有闭包看到的都是最后一次赋值的v - 即使
v是结构体，若含指针字段（如data *[]byte），仍可能共享底层数据
两种可靠修复方式及适用场景
核心目标是切断变量复用链，让每个闭包绑定独立内存地址。
-
推荐传参式：
go func(idx int) { use(idx) }(i)—— 语义清晰，Go 1.22+ 编译器对这种模式做了逃逸优化，性能无负担；适用于所有延迟执行场景（cron.AddFunc、time.AfterFunc、http.HandleFunc） -
局部副本式：
idx := i; go func() { use(idx) }()—— 更直观，适合复杂逻辑或需多次引用该值的场景；注意不能写成for _, v := range items { v := v; ... }来“修复”指针类型，那只是复制了指针本身，没解决底层共享问题 - 别用
func(v T) { ... }(v)注册回调：这是 IIFE，返回的是调用结果，而接口要求的是func()类型，会编译失败
闭包持有大对象引发的内存泄漏风险
闭包隐式持有所有捕获的变量。如果它被长期存留（如注册为 HTTP handler、存入全局 map、或后台 goroutine 未退出），而恰好捕获了 *http.Request、几 MB 的 []byte 或 context.Context，这些内存就无法被 GC 回收。
- 典型高危场景：HTTP handler 内启 goroutine 并捕获整个
req；定时任务闭包持有大缓存句柄 - 验证方法：用
go tool pprof查 heap，找那些生命周期异常长、且持有大对象引用的 goroutine stack - 缓解策略：只传关键字段（如
req.URL.Path），而非整个req；用sync.Once初始化时，确保返回的是已完全初始化完毕的不可变结构体，而非带指针的中间态
defer 中闭包捕获变量的隐蔽陷阱
defer 不改变闭包捕获规则，但它把问题延后到函数返回前才暴露——更难调试。
- 错误示例：
for _, f := range files { defer os.Remove(f.Name()) }→ 实际只删最后一个文件 - 正确做法：
f := f; defer func() { os.Remove(f.Name()) }()或defer func(f *os.File) { os.Remove(f.Name()) }(f) - 特别注意：若循环中 panic，这些
defer仍按 LIFO 执行，但绑定的f值已在 panic 前确定；若闭包内访问的是栈上局部变量指针，而函数已返回，就是野指针行为，可能 panic 或读错数据
真正容易被忽略的是：哪怕你只捕获一个 int，只要它被多个 goroutine 同时读写，就必须加锁或走 channel；闭包本身不提供任何线程安全保证，它只是个语法糖，背后全是裸指针操作。
