闭包在Go中是真实存在的funcval结构体，包含函数入口指针和捕获列表；捕获变量若被引用则逃逸至堆，触发GC压力，可用-go build -gcflags="-m"验证。
闭包在 Go 中不是语法糖，而是一个真实存在的结构体
Go 编译器把每个闭包编译成一个匿名 struct 实例，它包含两部分：指向函数入口的指针 + 一个捕获列表（capture list）。这个结构体就是运行时的 funcval，你能在汇编或逃逸分析输出里看到它。
关键点在于：闭包不是“把代码和变量打包”，而是“把变量地址塞进一个堆分配的结构体里，再让函数通过该结构体访问它们”。所以哪怕只捕获一个 int，只要它被闭包引用，就大概率逃逸到堆上。
- 用
go build -gcflags="-m" main.go能看到类似./main.go:7:6: &i escapes to heap的提示 - 捕获的是值还是地址？取决于变量是否被取地址或后续修改：未修改时可能拷贝值；一旦在闭包内写入（如
i++），编译器必然存储其地址 - 多个闭包实例（如两次调用
seq()）各自拥有独立的funcval结构体，互不共享捕获变量
为什么 i 没有留在栈上？逃逸分析的触发条件很明确
栈上变量生命周期绑定于函数帧。当编译器发现某个局部变量被返回的函数值所引用，且该函数值可能存活到外层函数返回之后，就会判定该变量“逃逸”。这不是推测，是静态分析的确定性结论。
常见触发场景包括：
- 外层函数返回一个匿名函数（最典型）
- 匿名函数捕获了外层的非 const 变量（哪怕只是读，某些版本也会逃逸；写操作则 100% 逃逸）
- 闭包被赋值给接口类型变量（如
var f interface{} = func() {}）
注意：func() int { return 42 } 这种不捕获任何外部变量的匿名函数，不会导致逃逸；但只要加一句 fmt.Println(i)，i 就很可能上堆。
高频创建闭包会加重 GC 压力，尤其在循环中
每次调用生成闭包的工厂函数（比如 makeHandler、seq），都会在堆上分配一个新的 funcval 结构体。如果在 hot loop 里反复调用，等于持续分配小对象。
- 一个闭包结构体通常几十字节，但频繁分配 → 触发 minor GC → 增加 STW 时间波动
- 若捕获的是大结构体或 slice，还会间接导致更多堆内存占用
- 替代方案：提前构造好闭包实例并复用；或改用带字段的 struct + 方法，避免隐式堆分配
例如：for i := 0; i 不仅 <code>i 逃逸，每次迭代还新建一个闭包结构体 —— 这里还有经典的变量捕获陷阱（所有闭包共享最后一个 i 值），但那是另一回事。
闭包捕获变量的方式影响并发安全性
闭包持有的是变量的地址（多数情况），多个 goroutine 并发调用同一个闭包，等于并发读写同一块堆内存。Go 不会自动加锁，也不会报错，但结果不可预测。
-
adder()示例中，若两个 goroutine 同时调用f(10)，x的自增可能丢失 - 没有内置机制区分“只读捕获”和“可变捕获”，全靠程序员控制访问模式
- 想安全共享状态？显式加
sync.Mutex，或改用 channel 通信，而不是依赖闭包隐式持有
真正容易被忽略的，是闭包结构体本身虽小，但它让原本栈上瞬时存在的变量变成了堆上长期存活的对象——而它的生命周期，只由 GC 根可达性决定，不再受你代码中“看起来该结束”的直觉控制。
