go闭包捕获变量的内存地址而非值快照，因此共享同一变量的所有闭包会反映其最新值；变量随闭包存活而逃逸至堆，避免被gc回收。
Go 闭包捕获的是变量的内存地址，不是值快照；只要闭包还活着，它捕获的变量就不会被 GC 回收——哪怕外层函数早已返回。
闭包捕获的是引用，不是值
闭包里读到的 i、name 或 config，都是指向原始变量的指针。你改它，所有共享该变量的闭包下次执行时都会看到新值。
- 基本类型（如
int、string）看似“值传递”，实则是共享底层存储：赋值操作本身是复制，但闭包绑定的是变量本身 - 结构体或切片被闭包捕获时，整个对象不会被拷贝；闭包持有的是原变量的地址
- 如果外层函数返回后，闭包仍被调用（比如注册为 HTTP handler、存入全局 map、传给 goroutine），被捕获变量会从栈逃逸到堆
for 循环中闭包全输出最后一个值？不是 bug，是引用共享
错误写法：for i := 0; i 输出全是 <code>3，因为所有 goroutine 共享同一个 i 变量实例。
- 根本原因：Go 不为每次循环迭代创建新变量，
i在整个循环作用域内只有一份内存地址 - 正确做法一：
for i := 0; i —— 短变量声明创建独立绑定 - 正确做法二：
for i := 0; i —— 参数传值，在注册时求值 - range 遍历同理：
v是复用的，不能直接在闭包里用；要用v := v或传参
defer 中闭包读的是执行时刻的变量值
defer func() { fmt.Println(i) }() 注册时不读 i，真正执行时才读——所以它看到的是函数返回前那一刻的 i 值。
- 常见翻车：
for i := 0; i 全输出 <code>3 - 想冻结注册时的值，必须显式复制：
for i := 0; i - 混合写法陷阱：
defer func(x int) { fmt.Println(x, i) }(i)——x是注册时值，i是执行时值 - 命名返回值会被 defer 修改：
func foo() (x int) { x = 1; defer func() { x = 2 }(); return }实际返回2
闭包延长变量生命周期，容易拖住大对象
只要闭包值还被引用，它捕获的变量就无法被 GC 回收。这不是泄漏，但可能造成意料之外的内存驻留。
- 典型风险场景：
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { use(r.Body) })→ 整个*http.Request可能长期驻留 - 排查方法：
go tool compile -m查看逃逸分析，确认哪些变量被抬升到堆 - 安全做法：缩小闭包捕获范围，比如只传
r.URL.Path而非整个r；避免捕获大 struct、大 slice - 最易被忽略的一点：这种内存滞留没有 panic、没有报错，只表现为服务运行越久内存越高，且 pprof 里找不到明显泄漏点
闭包不是语法糖，它是 Go 实现函数一级公民的核心机制；用好它的关键，不是背规则，而是理解变量何时逃逸、何时共享、何时被 GC。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
