for循环中直接用i启动goroutine会导致所有goroutine输出i的终值，因它们共享同一变量i的地址，循环结束时i已变为终止值。
for 循环中直接使用 i 启动 goroutine 总是输出终值
所有 goroutine 都打印同一个数（比如 3 或 len(slice)），不是因为并发调度慢，而是因为它们捕获的是同一个变量 i 的地址。循环飞快结束，i 最终变成终止值，而 goroutine 还没真正执行。
- 错误写法：
for i := 0; i → 输出全是 <code>3 - 根本原因：
i在栈上只分配一次，每次迭代只是改写它；闭包持有的是&i，不是i的副本 - 修复首选：在循环体内用
i := i重新声明 —— 这不是冗余，而是创建新作用域、新栈空间的独立变量 - 等效但更清晰的写法：
idx := i; go func() { fmt.Println(idx) }()
range 遍历中直接闭包捕获 v 导致结构体字段读错或 panic
哪怕 v 是结构体，for _, v := range items 中的 v 仍是复用变量。闭包若直接用 v.Field 或 &v，拿到的可能是最后一次迭代的残留值，甚至对已失效内存解引用。
- 危险操作：
go func() { process(v) }()→v可能被后续迭代覆盖 - 若需副本：显式赋值
item := v; go func() { process(item) }() - 若需原切片元素地址：必须用
&items[i]，绝不能用&v - Go 1.22+ 对
range的索引/值做了隐式按值捕获优化，但仅限切片和 map；自定义迭代器或传统for仍需手动处理
defer 中闭包读取的是执行时值，不是注册时值
defer func() { println(i) }() 不会在 defer 语句执行那一刻“记住” i 的值，而是在函数返回前、defer 实际触发时才去读 i 当前的内容 —— 中间可能已被修改多次。
- 典型翻车：
for i := 0; i → 全部输出 <code>3 - 安全写法一：
defer func(val int) { println(val) }(i)—— 参数在 defer 注册瞬间求值 - 安全写法二：
i := i; defer func() { println(i) }()—— 切断外层变量复用链 - 命名返回值 + defer 修改会改变最终返回值，容易被忽略：函数
func foo() (err error)中defer func() { err = fmt.Errorf("wrapped") }()会覆盖 return 行设定的值
闭包捕获大对象引发堆逃逸与 GC 压力
只要闭包被传给 goroutine、存入全局变量、作为返回值或塞进切片，它捕获的变量大概率逃逸到堆 —— 即使只是一个 int，也会触发堆分配，连带整个闭包上下文。
- 验证方式：
go build -gcflags="-m -m main.go，看是否有escapes to heap - 高频场景下影响明显：HTTP handler 每请求生成闭包 → P99 延迟上升；热循环中反复创建 → GC 频次增加
- 规避建议：优先用参数传值替代捕获；状态复杂时，改用结构体 + 方法，内存布局更可控
- 注意：哪怕只捕获结构体一个字段，整个结构体也可能逃逸（Go 当前不支持字段级逃逸分析）
