匿名函数必须参与执行上下文才合法：赋值给变量、作为参数传入、立即调用；孤立声明func(){}会编译失败，defer后也须加()执行。
匿名函数必须参与执行上下文才合法
Go 不允许写一个孤立的 func() {} 然后换行——这会直接编译失败，报错类似 syntax error: unexpected newline, expecting semicolon or }。它不是“风格问题”，而是语法硬性限制。
合法用法只有三种：赋值给变量、作为参数传入、立即调用。哪怕只是用于 defer，也必须带括号：defer func() { log.Println("cleanup") }()，漏掉末尾 () 就只是声明，不执行。
-
add := func(a, b int) int { return a + b }—— 赋值后可多次调用 sort.Slice(data, func(i, j int) bool { return data[i] —— 作为回调参数-
func() { fmt.Println("init") }()—— 自执行，常见于 init 块或配置加载
闭包默认捕获变量引用而非值
这是最常踩坑的地方：for 循环中起多个 goroutine 或注册多个回调，结果全打印出循环结束后的最终值（比如输出 3 3 3 而非 0 1 2）。
根本原因不是“i 变了”，而是所有闭包共享同一个 i 的内存地址。Go 闭包捕获的是变量本身，不是快照。
- 错误写法：
for i := 0; i → 全部输出 <code>3 - 修复方式一（推荐）：
for i := 0; i —— 在循环体内用 <code>i := i创建新绑定 - 修复方式二：
go func(val int) { fmt.Print(val, " ") }(i)—— 显式传参，切断引用链
闭包影响逃逸分析和内存分配
哪怕逻辑完全一样，只要形成闭包，编译器就更倾向把被捕获的变量分配到堆上。因为闭包可能跨栈帧存活，而栈生命周期不可控，编译器选择保守策略。
高频创建闭包（比如在 hot loop 中反复生成）会显著增加 GC 压力。这不是理论风险，是真实可观测的性能拐点。
- 验证方法：
go build -gcflags="-m" main.go，观察是否有... moved to heap提示 - 大对象（如长切片、结构体）被闭包长期持有时，无法被 GC 回收 —— 尤其当闭包注册为全局 handler 或存进
map/channel - 若只需一次性计算，优先用立即执行匿名函数隔离作用域，避免无意形成闭包
闭包变量生命周期由闭包决定
被闭包捕获的变量不会随外层函数返回而销毁。GC 会一直保留它，直到闭包本身不可达。这既是能力，也是隐患。
典型场景：工厂函数返回的计数器、HTTP 客户端预绑定 token、事件监听器携带 context。它们依赖闭包延长变量寿命；但若闭包意外泄漏（比如塞进全局 map 却忘了清理），变量就永远滞留堆中。
- 检查泄漏：用
pprof查看堆内存中是否存在预期外的长期存活对象实例 - 注意：每次调用工厂函数（如
newCounter()）都会生成独立闭包，各自持有独立的count变量，互不影响 - 不要假设“闭包用完就释放”——它的生命周期取决于引用它的闭包是否还被其他变量持有
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
